use Perl

brian d foy wrote a post about his keynote at the Portuguese Perl Workshop. As one of the main organizers, I think I should give the example. So, here I go.

The person who introduced me to Perl showed me that... it was concise and similar to C.

I first starting using Perl to... build a simple digital library on the web.

I kept using Perl because... it was used on some computer science classes for Natural Language Processing.

I can't stop thinking about Perl... because I like all that underlining magic.

I'm still using Perl because... there isn't any other language with such a wonderful and lazy community (and CPAN). Also, because Perl let you make your things done!

I get other people to use Perl by... teaching the Perl during Natural Language Processing classes, and by showing them how things can be wrote easily in Perl.

I also program in C, and I can't say I like more Perl or C. Different languages for different things. Sorry, brian!

On TPF webblog (check links bellow) are a set of posts with proposals received by the Perl Foundation grants committee during the second call for grant proposals for 2008. Although not usual, the rules of the TPF GC are changing and we hope to make this a rule. Proposals are accepted during one month and after that period, they are posted for public discussion on the Internet. This is important to make GC more aware of the community interest on the project, and to help opening the grants attribution process.

During the month of April we received the following grant proposals:

• Perl 6 Tables
• Solidifying and Extending the Blog Normalize project
• Add Perl support to NetBeans
• Perl on a Stick
• SMOP - Simple Meta Object Programming
• Fixing Bugs in the Archive::Zip Perl Module
• CatalystX::Installer Application
• Perl Survey
  
• Revision Control for all CPAN
• Improve POE::Component::IRC
• DBEditor
• Extending BSDPAN

Please take some time on reading the proposals carefully and give some feedback on the relevance of the proposals.

Archive::Any is a small and nice module by Clint Moore to manage ZIP and TGZ files. It also includes some kind of plugin system to be able to open other archive types as well.

Meanwhile, Clint does not release any new version since November 2006, and there is a critical bug reported since January 2007. A simple bug on a test that makes CPAN to fail installing Archive::Any if Test::POD::Coverage is not installed.

Given this, I am willing to fix this module and release it. But for that, I would like first to ask if anybody knows Clint, so I can contact him first.

This is strange... use.perl doesn't have Perl as a Journal Topic. Anyway, I think I wrote about this previously, but now I performed some more tests, and thus, here goes some new results. The idea is to compare the new say function to the print function with a new line at the end of the string. To test this, I used the Benchmark module, and two groups of functions: functions that print a string, and functions that print a string with interpolated variables (a scalar and an array).

The four benchmarked functions were:

our $var1 = "!";
our @var2 = qw!Hello World!;

sub print_hello { print "Hello World!\n"; }

sub say_hello { say "Hello World!"; }

sub print_hello_vars { print "@var2$var1\n"; }

sub say_hello_vars { say "@var2$var1"; }

The number of iterations was 10,000,000. Given that all these functions print to the standard output, I redirected the output to a temporary file. Also, and to raise the quality of the test, I ran this benchmark three times.

Now on the results. Do you have any idea of the ordering? Well, first the results were not always the same: say and print swap positions some time. In any case, interpolating on a say is faster, it seems. Check for yourself the three test results:

                      Rate    printI     sayI    print      say
printInterpolate 1587302/s        --     -18%     -67%     -70%
sayInterpolate   1945525/s       23%       --     -60%     -63%
print            4807692/s      203%     147%       --      -8%
say              5208333/s      228%     168%       8%       --

printInterpolate 1647446/s        --     -10%     -66%     -68%
sayInterpolate   1828154/s       11%       --     -62%     -64%
say              4830918/s      193%     164%       --      -6%
print            5128205/s      211%     181%       6%       --

printInterpolate 1652893/s        --     -10%     -67%     -68%
sayInterpolate   1831502/s       11%       --     -64%     -64%
say              5076142/s      207%     177%       --      -1%
print            5102041/s      209%     179%       1%       --

The Perl Foundation is looking at giving some grants ranging from $500 to $3000 in May 2008.

In the past, we've supported Adam Kennedy's PPI and Strawberry Perl, 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 April 30.

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.

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 tpf-proposals@perl-foundation.org.

On May 1st submitters will be contacted individually regarding whether they will let their proposal details be available for public discussion, as public views of grants proposals is likely to become part of the standard in the future.

Today my Arch Linux updated its Perl package to 5.10.0 (finally). But, unfortunately, configured in a strange way. Why to put binaries under /usr/bin/perlbin/vendor and /usr/bin/perlbin/site?

I mean, I know that there is that option in the configure script. But the default options (the one that the experts think are the more adequate) put them all together under /usr/bin.

Now I am compiling Perl by hand (not anything I never did before). I hate to do this, as it breaks the way package updates work.

Jspell is a morphological analyzer. If you do not know what that is, I explain: it is the more basic tool one needs to write Natural Language Processing tools. It takes words, and gives information about it: morphological category (verb, noun,..), gender, number, and more information.

Jspell is based on the well known ispell spell checking software by Geoff Kuenning. It was enriched to support morphological information, and to support easily the Portuguese language. At the moment I can say that Jspell is one of the most used open-source morphological analyzer for the Portuguese language.

If you download the current stable version of Jspell, you will find a autoconf/automake/libtool bundle, with a Perl module somewhere inside.

During the last week I have been working on changing this to a standard Perl module that includes the C program. Why? Because all users I know that use Jspell take advantage of the Perl interface. Thus, I created Lingua::Jspell.

Although Michael Schwern implored to change to Module::Build, it is based on ExtUtils::MakeMaker. This because I know more about EUMM, and because Schwern implored too late.

The last few days were on porting Lingua::Jspell to Windows. If Ken Williams apply my patch to ExtUtils::CBuilder, Lingua::Jspell should compile correctly using strawberry Perl.

I hope to include some tests soon on the distribution, so I can you ask you all to test this package on different architectures.

Installed strawberry Perl on my Windows XP, so I can test my Perl modules.

One of the modules I am writing at the moment is based on a big quantity of C code. Fortunately strawberry Perl includes a version of MingW C compiler, and a standard C library (unfortunately a little limited, as it does not include standard POSIX functions like sleep or mkstemp). In any way, after a day of C programming, my program compiled without major warning.

My problem, at the moment, is running the program. I have a strange problem with the open and read C functions. As I made a post on my blog about it, if you feel you are able to help me, please visit it at http://null.perl-hackers.net/2008/03/cant_understand_this_c_thingy.html.

Thank you in advance!

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

In the past, we've supported Adam Kennedy's PPI, 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 reason to believe that you can accomplish your goals.
• We can afford it.

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 tpf-proposals@perl-foundation.org before January 31.

If you have an idea for doing some work for the Perl community and you think it’s worthy of a grant, please send your grant entry to tpf-proposals@perl-foundation.org. Submission deadline is the last day of November, voting starts in December and we will be awarding the grants by the beginning of January.

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:

• It has widespread benefit to the Perl community or a large segment of it.
• We have reason to believe that you can accomplish your goals.
• We can afford it (we rarely approve anything more than a couple of thousand dollars).

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.