May 2010 Archives

Class custom dumping for Data::Dump

I'm using DateTime objects a lot these days: anytime I get some date/time data from outside of Perl, the first thing I do is convert them to DateTime object, to avoid calculation/formatting hassle ahead.

However, the dumps are not pretty.

% perl -MDateTime -MData::Dump -e'dd [DateTime->now]'
[
  bless({
    formatter       => undef,                                         
    local_c         => {
                         day => 21,
                         day_of_quarter => 51,
                         day_of_week => 5,
                         day_of_year => 141,
                         hour => 8,
                         minute => 55,
                         month => 5,
                         quarter => 2,
                         second => 36,
                         year => 2010,
                       },
    local_rd_days   => 733913,
    local_rd_secs   => 32136,
    locale          => bless({
                         "default_date_format_length" => "medium",
                         "default_time_format_length" => "medium",
                         en_complete_name => "English United States",
                         en_language => "English",
                         en_territory => "United States",
                         id => "en_US",
                         native_complete_name => "English United States",
                         native_language => "English",
                         native_territory => "United States",
                       }, "DateTime::Locale::en_US"),
    offset_modifier => 0,
    rd_nanosecs     => 0,
    tz              => bless({ name => "UTC" }, "DateTime::TimeZone::UTC"),
    utc_rd_days     => 733913,
    utc_rd_secs     => 32136,
    utc_year        => 2011,
  }, "DateTime"),
]
It gets worse when you have some records each with DateTime object in it. That's why I added a couple of mechanisms to allow us to custom a class' dump.
$ perl -Ilib -MDateTime -MData::Dump -e'$Data::Dump::CUSTOM_CLASS_DUMPERS{"DateTime"} = sub { "$_[0]" }; dd [DateTime->now]'
[2010-05-21T08:57:45]

or:

$ perl -Ilib -MDateTime -MData::Dump -e'package DateTime; sub dump { "$_[0]" }; package main; dd [DateTime->now]'
[2010-05-21T08:58:09]

I know some other dumper in CPAN probably has this ability, but I like Data::Dump's output.

If you want to take a look at a couple of small patches to Data::Dump: http://github.com/sharyanto/data-dump

Bleg: Why the alternating result?

I know I made a mistake by doing a double glob, but why this pattern of output? Note, there is only one file matching /etc/magic.* and two files matching /etc/magic*, and none matching /etc/magic.dragon*

% perl -E'say (glob </etc/magic.*>) for 1..10'
/etc/magic.mime
2
/etc/magic.mime
4
/etc/magic.mime
6
/etc/magic.mime
8
/etc/magic.mime
10

% perl -E'say (glob </etc/magic*>) for 1..10'
/etc/magic
/etc/magic.mime
3
/etc/magic
/etc/magic.mime
6
/etc/magic
/etc/m…

On RJBS's automatic version numbering scheme

Everytime I browse through CPAN recent uploads, and see versions of modules with RJBS's automatic numbering scheme, like 2.100920 or 1.091200 I tend to read it as 2.(noise) and 1.(more noise).

The problem is that it doesn't look like a date at all (is there any country or region using day of year in their date??). I've never been bothered enough with this though, as I don't use this scheme myself, but have always had a suspicion that this obfuscation is deliberate for some deep reason.

Turns out that it's ="ht…

perlmv: Renaming files with Perl code

perlmv is a script which I have personally been using all the time for years, but has only been uploaded to CPAN today. The concept is very simple, to rename files by manipulating $_ in specified Perl code. For example, to rename all .avi files to lowercase,

$ perlmv -de '$_=lc' *.avi

The -d option is for dry-run, so that we can test our code before actually renaming the files. If you are sure that the code is correct, remove the -d (or replace it with -v, for verbose).

p…

Spot the error

Spent 10 minutes the other day scratching my head after my Perl code stopped working following a single added line (can you guess which one?):

LABEL1:
my @var;
for (...) {
next LABEL1;
}

The error message is "Label not found for 'next LABEL1'. I think Perl could be better at handling this kind of mistake.

So is wantarray() bad or not?

The style of returning different things in list vs scalar context has been debated for a long time (for a particular example, this thread in Perlmonks).

A few months ago I made a decision that all API functions in one of my projects should return this:

return wantarray ? ($status, $errmsg, $result) : $result;

That is, we can skip error checking when we don't want to do it.

Now, in the spirit of Fatal and autodie, I am changing the above…

About Steven Haryanto

user-pic A programmer (mostly Perl 5 nowadays).