In my previous post, I asked for critique and suggestions for a Moose alternative to my app's handrolled AUTOLOAD implementation of

1. constructor attributes overriding same-named object methods, and
2. constructor attributes overriding object proxy methods

I asked, because this is the most complicated behavior of my OO code, and would be a key issue in porting the code to Moose. I also wanted to know if there would be other benefits to using Moose for this app.

Unlike my earlier OO-related posts, no comments appeared.

After some days, Aristotle replied that he believes my question was Warnock'ed (ignored) because the description lacked specifics.

Here is my attempt to provide them. Since I'm not sure exactly what to include and what to exclude, I'm documenting the process of generating the signal routing specification for a run of the Ecasound audio engine.

The Load from YAML::XS eats up quite a bit of memory, and it's deadly when I have to process a couple of hundred thousand YAML files. It still works, but the memory footprint grows without limit, and then it takes forever for the module to release all the memory at the end of the program. I actually got wise this time and checked the RT queue before I started and found the fix, which I only had to adjust a tiny bit.

RT 46172 has a patch for an earlier version of YAML-LibYAML, and also my adjustment for the latest issue. I've sent off a pull request for Ingy's YAML-LibYAML Github repo.

The patch works for me, but I'd also like to know if it works for other people.

Анонс выпуска №2

В очередном выпуске YAPP мы поговорим о новостях в perl мире, об источниках информации о perl на русском языке и немного о новых и обновленных модулях на cpan.
Если и у вас есть какие-то новости, которые кажутся вам интересными, присылайте ссылки на них и мы с удовольствием озвучим их.

Свои предложения Вы можете писать
в twitter: twitter.com/yapp_ru,
по почте: yapp_ru@gmail.com,
в jabber: yapp@demond.org
или в комментариях к данному анонсу на blogs.perl.org
по адресу: https://blogs.perl.org/users/perl_demon

Whenever I do anything new with web development I always remind myself to record it somewhere for future reference and for use by others - and, selfishly, to get their feedback. So after years of (not) doing that (un)successfully, I finally opened a techie blog.

This past weekend I dusted off my copy of Sam Tregar's Writing Perl Modules for CPAN. The book was published in 2002 and that gave me some trepidation about re-reading it almost nine years later. However, I not yet written a CPAN module and I wanted to give it a shot -- so this seemed like a logical place to start. Thankfully, any reservations were misplaced: this book should be on the shelf of any person wanting to expand their Perl repertoire.

Here's a quick summary of what really stood out for me this time:

HTML::Scrubber appears unmaintained at present, and I cannot find a way to contact the author (podmaster) - email bounces and I cannot see any activity later than 2006.

If you know a means to contact podmaster aka D. H. then I'd appreciate it if you could put us in touch so I can see if he would be open to an offer of co-maintainership or handing the module over.

For an application of mine which does very long-running requests (the server needs to communicate with a slow backend over the internet), I wanted to show the user a progress bar. Also, it should not just display some progress, but the real deal (communicate with the server to find out the current progress), because the browser already just displays some progress.

So, to outline my idea: When the user sends a request to the route, let’s call it /long, Dancer would immediately return a page with a little javascript that periodically calls /progress and updates the progress bar. When /progress returns undef, the operation is done and the user gets redirected to the /success route handler.

I came across a nasty bug in Firefox 4 today, which will break a lot of AJAX.

All script tags fire, except for the last one, eg:

function test(num) {
    var temp = document.createElement('div');
    var src  = '<script type="text/javascript">' +
                       'alert("Hi");'  + 
                    '<' + '/script>';
    if (num === 2) {
        src = src + '<script></' +'script>';
    }
    temp.innerHTML = src;
    body.appendChild(temp);
}

Calling test(1) will do nothing, while test(2) will produce an alert popup.

Reported as bug: https://bugzilla.mozilla.org/show_bug.cgi?id=645115

My first use with the great Template Toolkit was for generating SQL queries using configuration files and templates .

I really was impressed by the number of options !

Now it saved me from spend tons of my time to code my Perl project and my dog Ugo is more happy since now I have more time to go out :-) .

Read the full article Source code generation with Template Toolkit for details .

#!/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";

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

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

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.