blogs.perl.org

After Matt Trout visit to Portuguese Perl Workshop I got convinced to join this contest. I am not sure if I will maintain my posts in English, or if I join Portuguese from time to time. Just keep visiting.

Days ago, I was learning to use CGI::Application.

After finished my baby "run mode", I opened my browser to give it a shot. It worked, and I start wondering why it worked. The last statements of those examples are

return $output;

Mine's not, it looked like this(I forgot to add "return" by accident):

sub run_mode_1 {
    my $self   = shift;
    my $query  = $self->query();
    my $output = q[];
    ... ... 
    $output .= $query->end_html;
}

La función split nos sirve para separar por medio de expresiones regulares un string o cadena en varios elementos.

A long time ago, I wrote this regex to handle a Perl problem I had:

$html =~ s{
             (<a\s(?:[^>](?!href))*href\s*)
             (&(&[^;]+;)?(?:.(?!\3))+(?:\3)?)
             ([^>]+>)
          }
          {$1 . decode_entities($2) .  $4}gsexi;

It didn't work. That not only taught me how to use a proper parser, it led me to write HTML::TokeParser::Simple.

However, some people still insist upon using regular expressions for parsing HTML.

How do you know when you should use a module instead? When the risks outweigh the rewards. Otherwise, go ahead and use that regex. We're here to get jobs done and we should know when is the right time for dogma and when is the right time to extract that href. Don't be afraid to use Perl.

(And when it's a full-blown production system and it's critical that the information is correct, I'll be the first to yell at you for the regex).

I was pretty excited today because I thought I had my interface for ffi_call working on Linux, and told Twitter and the #soc-help channel all about it. It did seem to be working, until I changed a slight detail in my test script and it became apparent that either there was bewitchery afoot, or I need to read perlxs / perlguts more and it was random change that it hadn't blown up in the first place. I think I'm nearly there though. Next step will be fleshing out the OO functionality in Perl for a bit before diving back into the C for callbacks.

Dear Authors,

Please be aware that you may have received Daily Summaries from the CPAN Testers, that list the archname/platform as i686-linux, but the report in question is from a MSWin32 OS. We are aware of the issue.

Unfortunately, due to an untraditional smoker setup, the tests are run on a Win32 machine, but saved to disk as text files, then parsed on another machine, a i686-linux box, before being submitted to the CPAN Testers servers. As such the metadata sent with the report is misleading, even though the original text report is valid.

As a result, I will be running some validation checks over the weekend on all recent reports (those submitted in 2010) to ensure we have platforms and osnames that correspond with each other. Those that differ will be reparsed and the metadata will be updated accordingly. Further validation checks on incoming reports will also be added to ensure we catch any similar inconsistencies as soon as possible.

Apologies for any confusion.

Thanks,
CPAN Testers.

The Perl Survey 2010 is now closed. A quick preliminary look at the data set indicates that of the 4847 responses, 3256 were complete responses (by looking at who answered the final question). I'm on my way to German Perl Workshop tomorrow, and as I'm coming from Australia, it's going to take me over 24 hours to get there I'll have plenty of time to prepare the data and get a preliminary analysis going during that time.

Most importantly I'll be able to release the (lightly processed) raw data for you by that time as well.

I've just updated a syntax highlighter bookmarklet I wrote a while back so that it now supports Chrome and Safari, besides Firefox.

I find it useful to syntax highlight when I peek at a module's source code in the CPAN website. You may find it useful too.

To install it, create a new bookmark and paste the following code into the location field (sorry, I couldn't find a way to post this as a javascript: link in this blog):

It will be even handier if you stick it in your bookmark toolbar.

Then view any module's source in CPAN, fire off this bookmarklet and voilà.

I've even thrown in some regex to allow linking from one module to the next. It works 90% of the time, moreless.

The code is actually kept here. There you'll also find a lushier, Alex Gorbatchev's syntax highlighter version available, but I couldn't get it to work in Chrome nor Safari, only in Firefox.

It should be easy to tailor these bookmarklets to fancy your taste buds.

I have an RFC patch series to Git to add gettext localization support to it. So that eventually you'll be able to configure Git to e.g. shout error messages at you in German. Won't that be a nice variant of the current abuse? I think so.

Here's the latest version of the patch series I posted to the Git mailing list.

For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.

Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.

Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.

Beyond obvious problems with not using strict and warnings, here are some of my personal pet peeves regarding common Perl bad practices.

• Stop using indirect object notation

We already know it leads to subtle bugs. Why keep doing this?

my $foo = new Foo('baz'); # bad!

• DontUseCamelCase except for package names.

You want people to be able to read your code.

$foo = $DontUseCamelCase;
$foo = $do_use_underscores;

From "perlstyle":

While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

I could be mistaken, but I believe CamelCase was largely a holdover from Smalltalk which only allowed a leading letter and then optional letters and digits. TheReadabilityOfPerlIsBadEnoughWithoutCamelCase.

• Don't use Perl's lesser-known built-in variables unless you document them.

Actually, shared hosting - in terms of quality - usually sucks big time.

However, some of us are (hopefully only) forced to use it. If you're one (or simply want to show off to someone else who is), this is where Patrick Donelan comes in.

If you aren't on (or following) Iron{Wo,}Man, you should know that that Patrick has set up a website for Perl on shared hosting following an interesting blog post on the subject, named Serve Up Dancer Webapps for Six Bucks.

Serious kudos, Patrick!

(and yes, extra points for using Dancer in the demo! :)

Further beta testng has been ongoing over the last week and all seems to be working well. The metabase search problem, although not resolved completely, now has a mechanism in place to avoid blockages. The feed started up again last week and after 3 days had caught up with a month's worth of reports submitted to the metabase. Although this is still in the beta phase, it does give us more confidence that the eco-system can cope with the submission levels we have been seeing in the last year, and has the capacity to cope with much more. Further tests are being carried out, but the days of CT1.0 are definitely numbered now.

Thanks to all for the wonderful response rate. At this point we're a little over the 3,000 mark. I'm going to close the survey down at 7:00 am UTC on Thursday the 3rd of June, so if there are people you think still need to answer the survey, please point them at http://survey.perlfoundation.org.

I'll process the data file to make it useful over the weekend, and have a preliminary report ready early next week.

I've only recently taken on the tremendous task of learning Perl (with the aide of O'Reilly's Learning Perl). I have a little background in programming as I am a Computer Engineering & Computer Science student at the Florida Institute of Technology. Actually, I was a student there. I can't quite afford it at this point, and I'm going to attempt to transfer elsewhere (UCF, USF, UF? Something with a U and an F, I'd suppose).

Well, on to something a bit more on-topic. I'm midway through Chapter 5 in Learning Perl and I felt the need to create something that the book didn't explicitly tell me to. I eventually want to build my own forums software, but this small 'Journal' or 'Diary' script will have to do for now.

#! /usr/bin/perl

print "Press CTRL-D to end journal entry.\n";
my $success = open LOG, ">>logfile";
if ( ! $success) {
die "Cannot create logfile: $!";
}

select LOG;
print "\n\n", scalar localtime(), "\n";
print <STDIN>;

Seems like Padre (the Perl IDE, ya know...) got some heat for using a Trac bug tracking system instead of the default CPAN RT system.

Dancer, as mentioned in Gabor's post, prefers to use the Github Issues ticket system to keep track of bugs, wishes, expected features, etc.

I agree there's a certain barrier to provide bugs for Padre and Dancer or any other project that uses a non-CPAN-RT ticket system. I personally hate registering for websites and have decided not to file a bug more than once because I had to register. (case in point: notifying Yahoo! someone is abusing their mailing list system for SPAM.)

Some days are just big buckets of fail. So far I've not been able to get any code to successfully publish anything to blogger.com. I've failed with both Net::Blogger and Atompub and am seriously tempted to just create a bunch of damned HEREDOCs and push them straight to the Google Blogger API.

Didn't we use to own the Web? Or maybe I'm just having a really off day. I've successfully written a custom CMS in just a few hours and I'm stuck on one last, little stumbling block.

Anyone have working code they care to share? I mean real, live working code, not examples. I've seen more failed examples than I care to admit :)

• Can it be compared with J2EE?
• CGI? That's even older than ASP, you cannot write my webapp in it!
• Does Perl support session?
• I can let you try to code at most 20% of my webapp(you can't code the whole site with Perl, apparently), but make sure it can share session with ASP.NET.
• What's needed to run your Perl?
• Is there anything Perl can do better than Java?
• Does Perl have business value?

Like Damian said in this interview: "Selling Perl to your manager is about explaining Perl in terms that your manager cares about: stable, reliable, powerful, efficient, cheap, maintainable, well-supported, and future-proof."

Are we sharing the same situation here?

I previously wrote about trying out MooseX::Method::Signatures. That module is neat, but incurs a significant runtime penalty per subroutine call.

Now I've tested out Method::Signatures::Simple. It's powered by Devel::Declare and doesn't seem to incur a any runtime penalty. However, since it needs to do some work when the subroutines are compiled, there's a 3-4% compilation hit for my tests:

But on runtime there's no hit at all:

Here's what I needed to do to convert Hailo to it. Unfortunately using it breaks interaction with Devel::NYTProf. When I generate profiling output with nytprofhtml what were previously links to my subroutines aren't links at all.

That's a big price to pay for just turning this:

Into this:

So unless I can figure out a workaround for that I won't be merging that branch.

I've been noticing more and more attention being given to environment testing. That is, part of your testing would be to check the environment you're on. Many Perl developers would probably hear this and say "yeah, well, that makes sense" - that is because many Perl developers already do it. Apparently the other developers are starting to catch on. :)

Test::SFTP was written to make sure my environment is okay. By "okay", I mean "consistent." Also, I really wanted to write a test module.

Originally I wrote Test::SFTP when Net::SFTP::Foreign either didn't exist or was in its very very early days. Point is, I didn't know it. I used Net::SFTP which uses in turn Net::SSH::Perl which - for those that do not know it - is a pure-Perl implementation of the SSH protocol. It's actually a pretty cool thing, except that the dependency is a complete nightmare (including GMP and half of Crypt::* namespace) and it's rather slow.

I'm getting married on June 20th. Leïla and I chose this date because it's my birthday. It's my birthday because I was born on Dies Martis xx Junius MCMLXVII, as calculated by: