blogs.perl.org

A relatively quiet month during March, although my thanks go to Leo Lapworth and Dave Cantrell for noticing and reporting bugs in the websites. Feel feel to report bugs you spot on the CPAN Testers websites to me directly (barbie@cpan.org), as if I'm not the person to deal with that particular website, I can re-direct you to the right person. You're also welcome to report bugs on RT, and as I get more of the individual websites on CPAN, it'll be easier to report bugs and feature requests directly for the respective website.

Work has been ongoing with releasing the website code, with the release of CPAN-Testers-WWW-Wiki, which contains the basic code to run the CPAN Testers Wiki. The data that is contained within the website has not been released, though it is available on request if anyone wished to use it. I'm currently working on packaging the CPAN Testers Blog in the same way, and hope to have that released later this month.

My last posting seems to have whet the appetite of a few people, or at least interested one or two enough to follow this project on GitHub. Today I'd like to delve deeper into how you can use App::Mist to deploy or distribute an application.

I gave a talk at OSDC.TW 2011 about PPM as yet another faster installer, and several modules I took over from Randy Kobes who passed away last year.

Compared to the transition from CPAN/CPANPLUS to App::cpanminus, PPM, which once used a remote API server but now downloads indices (summary) and store them in a local database, seems to be taking a different (or opposite) track. Its XML based spec is apparently old-fashioned (actually, the original Open Source Description spec, on which PPM spec was based, was deprecated years ago). And the one on the CPAN is way behind the one bundled in ActivePerl. Certainly it's not good for everyone.

I've released a new version of Excel::Writer::XLSX to CPAN with support for charts.

The output looks something like this:

The example program that generated it is here.

I'll be adding more features in the near future such as chart sub-types, formatting, hi-lo bars and droplines.

If you are already using the Spreadsheet::WriteExcel charting features, or are interested in using this feature, try it out and let me know what you think.

Hi Folks

I'm beginning to transform a major part (but not all) of the osCommerce shopping cart into Perl. See osCommerce for details.

If you've already done so, and your code is open source, let us all know. Otherwise, I'll just keep grinding away, given that I've got the time and incentive to do so.

The namespace I intend to release it under is Business::Cart::Generic, and I'll be releasing another, restricted, version as Business::Cart::EdgarsMission.

The latter is an animal rescue group here in Victoria (Australia), who I've volunteered to help with their problem of charging people more-or-less accurate postage when they buy merchandise from Edgar's Merchandise.

The problem comes from being able to stuff 2 T-shirts, say, into 1 parcel, and thus not being able to justify postage on 2 separate T-shirts.

Basically, I'll keep track of purchases and with the aid of a special table of information (i.e. rules of thumb) from the chief packer of merchandise, I'll determine which sized package can be used for all the common combinations of merchandise.

Naturally this system will not be exact, but they are prepared for that.

I volunteered thru Good Company.

Compiling Perl on Unix is really straight forward, but on Windows you need to pay some extra effort .

If you want to build a default (a.k.a. Vanilla) Perl distribution on Windows with no pain read the following concise article:

http://perl-node-interface.blogspot.com/2011/04/compile-vanilla-perl-on-windows-with.html

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