blogs.perl.org

Following my recent post on HTML::Scrubber, I have been given maintainership rights on the module.

So I have sorted all the urgen stuff, including the 3 separate RT entries for a tmp file vulnerability, and pushed a new version to CPAN.

Coincidently, whilst updating the Changelog, I noticed the last release was exactly 7 years ago. So, umm, happy birthday HTML::Scrubber 0.08, but you have now been superseded!

I generally use Compress::LZF as "an extremely fast (not that much slower than a pure memcpy) compression algorithm. It is ideal for applications where you want to save some space but not at the cost of speed".

Google recently released Snappy, previously known as Zippy, which "aims for very high speeds and reasonable compression" and is used in Bigtable.

And luckily gray recently released Compress::Snappy.

Whenever slinging data around the network or writing things temporarily to disk, it costs you almost no CPU to use lightweight compression and will save you some I/O. Which is good as processors are fast and disk and network are slow.

For permanent storage I still use gzip, zlib or bzip2.

Many years ago I wrote a set of scripts and modules that together formed a way for me to access eBay internationally. I frequently bought records from the UK, US, Germany and Australia, so those were the plugins that I focused on, but the intention was to allow more to interface to other eBay sites. I even did a presentation at YAPC::Europe in 2004, called The Perl Auctioneer, which explained my progress.

As part of the currency calculations and conversion, I used the same site that eBay themselves were using, XE.com. As I became more involved in other projects, and my international eBay buying declined, my efforts to finish and release the Perl Auctioneer waned. However, I was still using the currency conversion module, so released it as a stand-alone package. In time this became Finance::Currency::Convert::XE.

If you've got a CPAN mirror and you haven't had a chance to test out the instant update mirroring, I'm here to suggest you try it out. I had a few spare moments earlier this week to test it out and I'm happy to say that the setup is trivial. If you follow these instructions, you can get yourself set up in a matter of minutes. In my case it was installing a couple of modules and then firing up the sync from the command line. When I checked back later, I had around 9 GB of CPAN goodness. As it happened, I uploaded a dist via PAUSE later in the day. I remembered to check my new instant update mirror a few minutes later and yes, my upload was already available in the mirror.

BioPerl is again part of the Google Summer of Code! The Open Bioinformatics Foundation, which also includes BioPython, BioRuby, and others, has been accepted into the Google Summer of Code for 2011. We are actively looking for students interested in OBF-related bioinformatics projects; new ideas are welcome. Project ideas and other details can be found here:

• Main OBF GSoC page
• BioPerl-specific projects

There's a lot of FUD out there about the performance of various OO modules, particularly Mouse. So let's set it straight with some benchmarking.

I've chosen to simulate that buggaboo of OO performance in Perl, the simple accessor. The one that you're going to call millions of times and that you'll be sorely tempted to reimplement with a hash or tear all the argument checks out of for "performance". To make it a little more realistic, I'm checking both getting and setting as well as a simple argument check.

I am kinda beginner in Perl I should mention that I've worked for 3 months with Perl and I wanna share my experience in Perl with you

If you are working like me (which is unlikely) distributing and deploying your Perl5 projects poses a significant challenge. Managing self-contained projects has become vastly easier since the advent of local::lib, Dist::Zilla and App::cpanminus but the ever changing (and sometimes incompatible) nature of CPAN has bitten me more than once in my life as a coder. Here is how I try to solve this, judge for yourself if this approach has any merit and encourage me to go further down this path if you think it does.

One of the most simple things you can do with Perl, is process text files. For that, you usually use the diamond operator, you chomp the read line, and process, line by line.

This is great and works mostly of the times.

Or, in the other hand, works when you can control where your files, the ones being processed, come from.

Because, if you want to make a generic application, you need to know that when running on Unix, chomp will remove the newline, but not the carriage return character, unlike when the same script is run under windows.

And I think that is annoying.

Why should we base on the architecture we are running on and not in the file we are processing?

If there any situation where, when reading line by line, we want chomp to maintain the carriage return if it is there?

I know chomp removes the character defined by $/, and this character is different from operating system to operating system.

But is this behavior the one we really mean?

Or am I missing something, and there is something I can do with file handles (IO::Handle, afaik) that will guess the line ending?

There was a post in blogs.perl.org or Planet Perl Iron Man (sorry, forgot the exact article) that said something along the line of: "Benchmark is a fine module, but for simplicity I'll use the time command". Which immediately hit home with me, because I too very seldomly use Benchmark. I guess the problem is I almost always have to perldoc it before using it, and there are quite some extra characters to type.

So last weekend I wrote Bench (repo) that's hopefully simpler enough to get used more.

To benchmark your program, just type: perl -MBench yourscript.pl. Sample output:

$ perl -Ilib -MBench -MMoose -e1
0.229s

Bench exports a single function, bench(), by default. To time a single sub, use: perl -MBench -e'bench sub { ... }'. By default it will call your sub at most 100 times or 1 second. Here's a sample output:

258411 calls (129165/s), 2.0006s (0.0000s/call)

To benchmark several subs: perl -MBench -e'bench {a=>sub{...}, b=>sub{...}}' or perl -MBench -e'bench [sub{...}, sub{...}]'. Sample output:

a: 100 calls (12120/s), 0.0083s (0.0825ms/call)
b: 100 calls (5357/s), 0.0187s (0.187ms/call)

Bench will automatically use Dumbbench if it's already loaded, e.g.: perl -MDumbbench -MBench -e'...'. Or you can force Bench to use Dumbbench: perl -MBench -e'bench sub { ... }, {dumbbench=>1}'.

That's about it currently.

Modules mentioned:

Config::IniFiles
Config::Tiny
Config::Tiny::Ordered
DBIx::Admin::CreateTable
DBIx::Class
DBIx::Connector
File::HomeDir
Log::Dispatch
Log::Handler
Module::Build
Module::Metadata::Changes
MooseX::LogDispatchh
Plack
Perl::PrereqScanner
Role::Basic

Over the years I written quite a few modules, some destined for CPAN,
some for customers, and others - Local::* - for my own use.

For some days now I've been cleaning up the latter group, and I thought
I'd blog about the decisions involved.

o Config files

Firstly, I've kept the convention of starting all config file names with
'.ht', to make it easy of block downloads of such files, via various web
server options.

But I've changed my convention about where within a distro's directory
structure to ship such files. Originally if, say, a module was called
Local::Wines, then I'd use lib/Local/Wines/.htlocal.wines.conf.

A module, Local::Wines::Util::Config was dedicated to reading this
file, and performing some basic validation on its contents.

But now, a digression on the structure of such config files.

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 .