It is with great pleasure that The Perl Foundation and Mozilla Foundation announce a major new Perl 6 Development Grant. The recipient of the grant is Patrick Michaud, the Perl 6 compiler pumpking and lead programmer of a Perl 6 implementation based on Parrot and on his own work on the Perl 6 compiler and grammar. The grant will provide Patrick with four months of support for this work beginning November 1, 2007. Patrick will receive US$15,000 over this time, with $10,000 of the funding coming from Mozilla Foundation and $5,000 from The Perl Foundation.The goals for this development grant are:
In order to ensure the proper management and progress for this grant TPF asked Jesse Vincent to be the Grant Manager. Jesse has graciously accepted this volunteer position. Jesse is a noted Perl community member and he has worked as the Perl 6 project manager for the past several years. Additionally, he (through his company, Best Practical Solutions) has supported the Perl 6 effort through a series of microgrants.
Patrick Michaud and The Perl Foundation will provide grant progress updates and summaries at http://news.perlfoundation.org.
The San Diego Perl Mongers group will be having their regularly scheduled meeting at 7:00pm on Monday, November 12, 2007. Not so regular, however, is what we'll be doing. We have a presentation this month! David Moore will be joining us to talk about the different Perl/C interfaces, SWIG and XS. It should be interesting, so come on out and join us.
We'll be meeting at in Qualcomm's building Q auditorium.
6455 Lusk Blvd.
San Diego, CA 92121
Google Map (This is not quite right. The building is on the west side of Pacific Center Blvd. It's the building with the colorful roof.)
After re-implementing this by hand about a dozen times now, I've created a package to deal with it in a single method call. Win32::WebBrowser exports a single method, open_browser(), that pops open the default browser in a detached process and points it at a URL.
Who knows, maybe it'll make the Strawberry Perl dist...
We've just released Test::Harness 3.00. It's a complete rewrite of Test::Harness with a more modular architecture that should make it easier to write custom testing tools.
I recently had a few spare tuits and ran out of books to read, so the Moose object system popped to the top of my stack.
Like many new and cool projects, features are accellerating away from documentation, and often what a new starter wants is a low-down, which isn't there (yet). Catalyst and DBIx::Class were each like this at one point in time.
To help myself and others I have created a PDF Moose Quick-Ref Card with most of the functions and syntactic sugar consructs of the system.
Thanks go to folks in the
#moose IRC channel, and the Programming With Moose WikiBook written by EvanCarroll. The ref card will work best if you can print it 2-up on one A4 sheet, cut that in half, then laminate the two A5 parts back-to-back.
Comments and suggestions for the ref-card will be gratefully received
ack, my replacement for grep for 95% of the times programmers use grep, just got released to CPAN with version 1.70.
At long last, you can now get contextual lines before and after matched lines, just like GNU grep's -A, -B and -C options. You can also match on a specific line number or range of line numbers with the new --line option. For example, if you want to see the first line of every Perl file in a tree, you'd just do ack --line=1 --perl. Thanks very much to Torsten Biix for putting both these features together for me.
Finally, Elliot Shank pointed out that one of my favorite features, the -1 option, was never documented. Now it is. The -1 option says "stop after the first match of any type." If you find yourself acking for lines, or searching for a specific file with ack -g and then having to Ctrl-C to stop the search process, just add a -1 and Ctrl-C no longer.
ack is available in the ack distribution on CPAN, or by installing the module App::Ack from the CPAN shell. You can also download the single-file version direct from Subversion and drop it right into your ~/bin directory.
After successfully mapping 54 addresses from September up to mid-October, I sent out the six-month request to all outstanding addresses used so far this year. After only a short time I'd already received several emails from testers updating their details for me, mapping a further 14 addresses. It is notable that several new and current testers are now putting their names, or a least some form of reference in their addresses, that makes it very easy for my scripts to reference them, so thanks very much for that.
tarhas the annoying habit of generating extra files to represent Mac specific attributes. That's particularly annoying for CPAN authors because they tend to break your test suite and you can't easily see them without unpacking the archive on a non-Mac system. Grrr.
It used to be possible to disable this behaviour by setting the env var
COPY_EXTENDED_ATTRIBUTES_DISABLE to some true value - but this seems
to have stopped working in Leopard. As a result I've just released
a broken version of
Captcha::reCAPTCHA. Double Grrr.
strings /usr/bin/tar fails to reveal anything promising,
/usr/bin/gnutar is just a hard link to
/usr/bin/tar and I can't get the MacPorts
gnutar to build so for now
I've restored a copy of Tiger's
tar from a backup and dumped it in
~/bin (which I have
on my path). Phew.
Watch out Mac-based module authors - it's hard to detect that you have a broken archive without testing it on a non-Mac machine.
As previously reported progress on Test::Harness 3.00 ran aground temporarily while we worked out how to run our test suite on VMS. We're back on track now, running our smoke tests automatically on a VMS TestDrive account.
With help from Craig Berry and Michael Lemke I've put together a page on the Perl-QA Wiki that describes the process:
It includes a link to the script we use to remotely execute our test suite. If I've missed anything important or made any errors please feel free to dive in and fix them.
Which means that, occasionally, stuff like this happens:Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES
make: *** No rule to make target `/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE/config.h', needed by `Makefile'. Stop.
Debuggers, testers, parrotheads, and the C afficionados who read this (both of you) might appreciate two recent length weblog postings I've published at work, namely Debugging GC Problems in Parrot and How to Debug a GC Problem in Parrot.
I take a little credit for the highly abusive new Parrot runcore that nicely complements Valgrind in my toolkit.
First, please read about how to submit a grant. Read that carefully as grants are often rejected if they don’t meet the criteria. For example, if you want to submit improvements to a well-known project but there’s no evidence that you have at least tried to work with the maintainers of that project, the grant will likely not be approved. You can also read through our rules of operation for a better idea of the grant process.
To get an idea of what sorts of grants are generally accepted, you can read through past grants for 2001 to 2006. You can also read through the grant-related postings to the Perl Foundation blog. As a general rule, a properly formatted grant proposal is more likely to be approved if it meets the following criteria:
The thorniest issue, as always, is the grant amount. If you do not include a grant amount, the grant will not be approved. So how much do you ask for? While we have information in this posting about the grant committee, the reality is fairly simple. We’re a non-profit organization and we are not flush with cash. If you charge us a typical hourly rate, we probably cannot afford it. Typical grant awards are generally in the $500 to $3000 range, but we have gone under and over those amounts, depending on the grant. As a general rule the less expensive it is, the more likely it is that we can afford to fund it. For highly speculative grants (in other words, projects whose benefits may be unclear or have a high chance of failure), we are unlikely to risk large amounts of our donor’s money.