Day 14: What $! The $? (Proc::ChildError)

About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.

Finding out OS error message in Perl is pretty straightforward: just print out the $! variable. Example:

open my $fh, ">", "somefile" or die "Can't open file: $!";

The $! is pretty magical, it can return an integer (errno) or a string.

However, finding out child error message is not equally straightforward: there needs to be some bit-fiddling involved, which I always forget. To quote the perlvar manpage (or, perldoc -f system):

if ($? == -1) {
    print "failed to execute: $!\n";
}
elsif ($? & 127) {
    printf "child died with signal %d, %s coredump\n",
        ($? & 127),  ($? & 128) ? 'with' : 'without';
}
else {
    printf "child exited with value %d\n", $? >> 8;
}

I mean, are we really expected to do this incantation everytime we want to check the status ofsome command we launched using system()? So I wrote Proc::ChildError, which is just the above code packaged as a module. Thus you can say:

system "foo" or die explain_child_error();

Looking for new maintainer for Memcached::libmemcached

Howdy folks.

I offered to help Tim Bunce maintain Memcached::libmemcached earlier this year and managed to get a single release out with a few fixes.

I intended a second release to solve some compilation issues, but never got around it, and I'm not sure I ever will - there's still more work to do to there, and my time/interests have moved on.

I'm looking for someone to take over maintainership of this. Bug reports have been fairly minimal so far, most of it coming down to "Please update to latest upstream version" or "allow to link against system version instead of bundled version."

See https://github.com/timbunce/Memcached-libmemcached/issues for more about the above.

If this sounds of interest to you, please let me or Tim know - we'd love to have someone keep this going.

Thanks,

-- Matthew Horsfall (alh)

Announcing WebService::Vultr v0.1

Complete Perl bindings for the Vultr v1 API uploaded to CPAN.
The module is managed at: https://github.com/eskaaren/WebService-Vultr

Vultr is a global VPS provider similar to DigitalOcean and Amazon EC2.
http://www.vultr.com/?ref=6816711

(By signing up using that link and spending at least $10 I will get a one time kickback)

Day 13: *PAN

About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.

What is XPAN you say? I wanted to write *PAN, but since that is not a valid module name (or perhaps it is? maybe there's some word character somewhere in the set which resembles an asterisk/star?) I settled with XPAN. The XPAN::Query explains it and I quote: "XPAN is a term I coined for any repository (directory tree, be it on a local filesystem or a remote network) that has structure like a CPAN mirror, specifically having a modules/02packages.details.txt.gz file. This includes a normal CPAN mirror, a MiniCPAN, or a DarkPAN. Currently it excludes BackPAN, because it does not have 02packages.details.txt.gz, only authors/id/C/CP/CPANID directories.

Day 12: A fatpackable, SSL-aware HTTP::Tiny (but sadly, with a catch)

About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.

Okay, this one is a silly proof-of-concept, and currently incomplete. But nevertheless might fit your need in some situation, like for testing.

It all began a few weeks ago when MELO posted this blog post about his attempt to produce a fatpacked version of a chat client. At the end he failed because HTTP::Tiny depends on IO::Socket::SSL and eventually Net::SSLeay which is an XS module and cannot be fatpacked. So I got this idea of having an HTTP::Tiny variant which uses a CLI network client like wget or curl. Sure, we're just trading one dependency to another, but on a typical Linux system on the deployment, chances are it'll probably have either one. So an experimental module HTTP::Tiny::CLI is born. I don't know if it's going to be useful for somebody, but nevertheless I had a bit of fun writing it, so there you go.

Day 11: Tab-completion galore (App::{PM,Pl,Prog,Dzil,Git}Utils)

About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.

Ever since I got interested in doing shell tab completion with Perl, I've been trying to add tab completion to various programs or, in some cases, (re)creating utilities with tab completion capability. Granted, many of the utilities mentioned here are pretty trivial, but that's okay since tab completion is the main point. Here are some of them:

First of all, if you want to try these utilities out and you use bash, you might want to install and setup bash-completion-prog first. Just do a cpanm App::BashCompletionProg and put . ~/.bash-completion-prog in your ~/.bashrc. After that, installing the other utilities cpanm -n App::PMUtils App::PlUtils App::ProgUtils App::GitUtils App::DzilUtils will automatically add completion entries to ~/.bash-completion-prog so the next shell you start will automatically enable tab completion for all the included utilities.

What prevent warnings pragma become default feature?

What prevent warnings pragma become default feature by use VERSION?

In Perl 5.12, strict pragma become default feature by use VERSION .

  use v5.12; # enable strict pragma

Now many source code examples in web is written by the following way.

  use v5.x;
  use warnings;

If warnings is enabled by use VERSION, it is useful.

Day 10: Finding module's path and more (Module::Path::More)

About the series: perlancar's 2014 Advent Calendar: Introduction to a selection of 24 modules which I published in 2014. Table of contents.

NEILB's Module::Path is a handy little module (that comes with a handy little utility mpath to find the filesystem path to a locally installed module. It works by iterating @INC, pretty much like require() except it doesn't do coderefs like require().

You can use Module::Path to test whether a certain module is installed, for example. In my case, I'm using it to provide shell tab completion of Perl modules (will be covered in subsequent entry). However, I find it lacking some features. And after waiting for a while (not) getting my patches submitted/rejected, I launched a fork which, after several iterations, eventually called Module::Path::More.

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.