#!/usr/bin/perl
use strict;
use warnings;

print "Hello, world!\n";

Why Perl is Just Not That Into Your Syntax

In a previous post, I noted that Perl often cannot precisely locate syntax errors in its scripts. Still less can it identify the exact problem. In this post, I will demonstrate an experimental utility which does pinpoint Perl syntax errors, precisely indicating where and what the problem is.

Here's my example from the previous post.

my $lyric =
'Sloopy wears a red dress, yeah
As old as the hills
but when sloopy wears that red dress, yeah
you know it gives me the chills
Sloopy when I see you walking, 
walking down the street
I say don\'t worry sloopy, girl
You belong to me'~!@$%^&*()_+;
print "$lyric\n";

Jenkins works well when your Java code is based on the build philosophy of maven or ant and tucked nicely in one of the popular source code management repositories. (All your code is versioned, right?!?) Building a newly created project will retrieve your code and build it with the system default tools; maven, java or ant. One of the nice features is the additional "tools" you can install and use to build your projects. Install the 1.6.X version of ant in your node and select it when you create your new project. You'll see in your build output, a preliminary stage where it will install and execute your build.xml with the selected version. Wouldn't it be nice to have have that similar functionality with Perl?

If you're like me, you probably spend a lot of time looking at search.cpan.org. Occasionally I'll pull up perldoc directly in the terminal, but I love reading docs in the browser.

I also love syntax highlighting. To some, it's superfluous. To others, it's downright confusing. But for those of us who use it all day every day, it's an essential tool that helps us read and understand code more quickly and with less effort.

It's always been a minor complaint that search.cpan.org does not put syntax highlighting on the perldocs.

Of course there are other sites that do, but I'll confess to using Google most often to look up Perl modules. And in the land of search results, search.cpan.org is king.

So without further ado, I'm happy to say that search.cpan.org has syntax highlighting. :) If you scroll to the bottom of any rendered document, you will find a dropdown menu to choose your color scheme. I recommend the "cpan" color scheme.

And if you hate syntax highlighting, don't get your panties in a bunch: "no syntax highlighting" is the default choice.

Many thanks to Graham Barr for his wonderful cooperation, accommodation, and help. And to the creators of SHJS and the other tools that make this possible.

Let's face it: The promise of "PaaS" (Platform as a Service) -- easily deploying your application to a whole stack living up there in the cloud -- is pretty cool shit. Back in January (ages ago in Internet time), I kicked the tires of DotCloud and, after a whole three minutes, announced to the world "this is just too easy." No wonder they just raised a cool ten million.

Yet, still, there is not one PaaS solution for Perl today.

• Amazon Elastic Beanstock? Nope. Just Java. 
• Google App Engine? Nope. Just Java or Python. 
• Red Hat's Makara? Nope, no Perl. 
• DotCloud? Everything but Perl.

So, what gives?

Well, when I asked the DotCloud folks back in January, they indicated that Perl support is on their road map, but that they didn't have a sense of what the most common use cases for deployment are in the Perl community, for example CGI, FastCGI, etc.

One of my favorite things in Perl is of course local variables, a.k.a. dynamic scoping. After learning that you can localize just a hash pair, or an array element, I have often used local() as sort of a stack to save temporary results. Then a few weeks ago I was hit with a bug:

{
    local $ary->[-1] = $foo;
    manipulate_ary($ary);
}

which is okay, until I got carried away and shift(), pop(), splice(), et al on @$ary in manipulate_ary(), and expected local() to take care of everything. Of course it's not that magical.

Following the discussion on Daniel's Page you can also install perlbrew using wget similar to using curl.

wget -O- --no-check-certificate http://xrl.us/perlbrewinstall | \
sh | \
tee perlbrew_install.log | \
grep "bin/perlbrew init" | \
sh > perlbrew_init.log

If you don't have admin rights on your development box to install curl but do have wget available, this is an alternative to the instructions in the perlbrew pod.

What will MetaCPAN offer that other services don’t?

• Instant availability (new uploads are indexed within a minute)
• Personalisation - “follow your favourites”
• Searchable metadata
• Mashup of other CPAN related services
• Unified (REST) API
• Back-end for Android/iPhone apps, command line tools etc.
• MetaCPAN.local for companies
• Includes BackPAN as well
• Open-source and free

Now what?

Apply for GSoC to get this thing up and running

MetaCPAN is being developed by a group of perl coders who have jobs and all kinds of stuff on their minds. This means it is hard to get the momentum up. I got very much infected by the idea of having an API to CPAN that everyone could use and a front-end that could eventually replace search.cpan.org. So I joined the MetaCPAN group and started coding. And since I’m still a student, GSoC is a great opportunity to delve even deeper into the guts of MetaCPAN and do some serious work.

Community feedback to complete proposal

YAPP #1:

• Когда выйдет perl6?
• Сменит ли perl6 perl5?
• Modern Perl как явление.
• В чем perl5 проигрывает другим языкам?
• Как опеределить хорошего perl программиста.
• IDE: komodo Edit, vi.
• Сложность перлового кода — абсолютный миф!
• Книги для perl программиста: Modern Perl, Learning Perl, Perl Best Рractices.

Cсылки: RSS и лента на rpod.ru Следите за анонсами в twitter

I am as much a Javascript developer as a Perl developer, and that is primarily because of the striking similarities the languages share, one of the most useful of which is the concept of closures.
Having private(hidden) data, and public accessors/mutators has always been one of the key reasons people use the object oriented paradigm. Perl however, being the flexible language that it is, does not provide any direct way to hide the data in your objects. One of the solutions to this problem is inside-out objects (and I think it is a very elegant solution too.)
But, when I want to write lesser code, and don't really want to use all of Perl's OO functionality, I simply use closures.
Here's how,

gogod's perlbrew module allows one to perform some simple admin tasks so you don't need to have root access. After having installed it a few times over the last couple versions, I created a quick script to install and run the init on installation.

The output of the install contains all the info you need. (I guess this also adds a dependency of not only curl for installation but also grep and tee but they are found on most *nixs anyway.)

curl -L http://xrl.us/perlbrewinstall | \
sh | \
tee perlbrew_install.log | \
grep "bin/perlbrew init" | \
sh > perlbrew_init.log

In the future, watch for blogs entries as I attempt to create a development environment for perl on Hudson Jenkins.

Stricture helps me catch some typos by requiring predeclaration of variables (e.g. using the lexical my()). But it doesn't warn me about my stupidity. In this month alone, I have been bitten by two episodes of sloppy refactoring, where I left an extra 'my' on an inner block, something like:

my $foo = blah();
...
for (...) {
    my $foo = ...;
    ...
    # we lost what we've done to the inner $foo
}

Of course, -w and 'use strict' didn't help me here. -w only warns about the second 'my' if done in the same scope. And so around half an hour were spent chasing these two silent bugs. I guess a critic policy could be written for this sort of thing, e.g. forbidding two lexical declaration inside the same sub. And discipline yourself to keep paragraphs of code relatively short.

Exporting can be achieved through several routes. You can do it manually through typeglob manipulation, or you can use one of several modules that do it for you. One of the most proliferated, and common is the Exporter.pm module. More recently there have been some advances in the form of Sub::Exporter and similar improved exporting tools.

Exporter.pm is good in that it has a simple interface, is found in any perl installation, and is proven to get the job done. On the other hand it shows it's age; You specify exports in a package variable, and it can be difficult to work in custom import() logic.

Node programming is really interesting since makes possible to realize
a program even if you have no idea about programming.

Think about genetic researchers, for example.
They need to focus on protein chains, not on what is a package.
Maybe they can do an extra effort and say the world "variable" or "string"
or even "regular expression" and that makes them proud, but they don't care about inheritance.

They want things working and they need Perl ...
but if you say Strawberry they think about yogurth, not about Windows.

There are a lot of visual programming languages (VVVV, Puredata, Max/Msp)
but normally they target artists and interaction designers.
I saw a lot of vjs and musicians do really complex programs
with those softwares, and they never wrote a line of code.

This is my effort to provide a node interface that brings Perl power
to people who don't know the Perl language.

It is called PNI and stands for Perl Node Interface: it is at a very early stage but I would like to share it with this great community as well .

Any feedback/help is welcome, point your browser to PNI blog for more info .

We've just accepted our third round of talks for YAPC::NA::2011 in Asheville, NC! As always, just because your talk has not been accepted yet it does not mean that it will not be.

This also marks the last of our early acceptances. You now have just seven days to submit a talk for YAPC::NA::2011. We have roughly half of the talks we need, so please start submitting everything you can think of (toss rubber band airplanes around an auditorium, tell tales of undead email messages haunting your family, anything!).

I've just released a new version of WWW::Mechanize::Firefox, appropriating a new function of WWW::Mechanize, ->click_button. I used that occassion to also change the XPath queries sent by W:M:F to Firefox to be somewhat slimmer by changing queries for the element type from a global "OR" to a local test for the node name:

The old query to look for a <BUTTON> or <INPUT type="submit"> was

//button
|
//input[@type = "submit" ]

The new query is

//*[local-name(.) = "button" or (local-name(.) = "input" and @type="submit")]

If you're like me, over the years you'll have had your todo lists scattered over multiple programs and places. First a simple text file with homebrewn format, then various Windows programs, then various Linux GUI programs, then back to Notepad and joe/gedit/kate, then various apps on cellphones, then pencil & paper (due to cellphones keep getting lost/stolen), then some cloud apps, then todo.txt, then finally org-mode. And if you're anything like me or many others, you'll find that org-mode is *it*.

I'm now in the (long, boring) process of consolidating everything in Org. For todo lists, contact lists, and even long documents and all journals/diaries. I've written a preliminary version of Org::Parser to help automate stuffs via the command line. It only supports the basic stuffs at the moment but has been able to parse all my *.org files.

The code is available on GitHub.

A Faster Marpa

I've been converting Marpa from Pure Perl to C. For those who don't know, Marpa is a parser generator which parses any grammar you can write in BNF. If the grammar is one of those which can be parsed by yacc, by recursive descent or as a regular expression, Marpa parses it in linear time.

Marpa's core algorithm does no system calls. It is almost 100% pointer twiddling. There is no floating point, and very little integer arithmetic. It's as if it was made to order to show C in its very best light.

I expected converting the Perl implementation to C to improve speed by two orders of magnitude, and first results are close -- the speedup for the code converted to C is 95 to 1. The code converted to C remains wrappered in Perl. The Perl wrapper handles the I/O, the user interface, and roughly the last third of the core algorithm. This last part of the core algorithm I have yet to rewrite in C.

When I moved from OpenBSD to FreeBSD a year ago, I also had to move the email being handled by my server. As things were a bit different, I added a "Just-in-case" MailDir for one of my users so that no matter what else happened to the rest of their procmailrc, they'd have a backup copy.

Flash forward a year.

Yeah, you guessed it... we never turned that off. It's been accumulating spam at the rate of a few messages a second. For a year. I couldn't figure out why my 80GB of freespace a year ago was now dangerously under 15GB.

The MailDir/new directory was 2.5GB. Not the contents. The directory itself! I tried an "ls", realizing after a few minutes that ls would want to load the entire list of names into memory, then sort them, then dump out. Ouch.

http://perlnews.org/ has just launched and will be providing a source for major announcements related to The Perl Programming Language (http://www.perl.org/). Find out more at http://perlnews.org/about/ - or if you have a story submit it http://perlnews.org/submit/.

All stories are approved to ensure relevance.

Thanks

The Perl News Team.