• for, map, grep and function calls autovivify arrayrefs

    I was surprised by one aspect of Perl’s autovivification a few weeks ago, and I’m surprised it’s taken over 20 years for me to run into it.

    Read on →

  • ack 2.28 has been released with new color charts

    I’ve released ack 2.28 to the CPAN. This release doesn’t add any major new features, but for those who like to customize things, there are two new help options: --help-colors and --help-rgb-colors.

    Read on →

  • perl101.org needs a new maintainer

    My website perl101.org needs a new maintainer.

    Read on →

  • Announcing SQL::Tiny

    I just released a new module, SQL::Tiny. It’s intended for creating simple SQL statements where speed is not as important as having maintainable code.

    Read on →

  • Use Getopt::Long even if you don't think you need to

    Note: This is a post from 2008 that I dug up that still applies today.

    There's a thread over on perlmonks talks about Tom Christiansen's assertion that you should use it, by default, even when you only have one command-line argument to parse:

    What seems to happen is that at first we just want to add--oh say for example JUST ONE, SINGLE LITTLE -v flag. Well, that's so easy enough to hand-hack, that of course we do so... But just like any other piece of software, these things all seem to have a way of overgrowing their original expectations... Getopt::Long is just *wonderful*, up--I believe--to any job you can come up with for it. Too often its absence means that I've in the long run made more work for myself--or others--by not having used it originally. [Emphasis mine -- Andy]

    I can't agree more. I don't care if you use Getopt::Long or Getopt::Declare or Getopt::Lucid or any of the other variants out there. You know know know that you're going to add more arguments down the road, so why not start out right?

    Yes, it can be tricky to get through all of its magic if you're unfamiliar with it, but it's pretty obvious when you see enough examples. Take a look at prove or ack for examples. mech-dump is pretty decent as an example as well:

    GetOptions(
        'user=s'        => \$user,
        'password=s'    => \$pass,
        forms           => sub { push( @actions, \&dump_forms ); },
        links           => sub { push( @actions, \&dump_links ); },
        images          => sub { push( @actions, \&dump_images ); },
        all             => sub { push( @actions, \&dump_forms, \&dump_links, \&dump_images ); },
        absolute        => \$absolute,
        'agent=s'       => \$agent,
        'agent-alias=s' => \$agent_alias,
        help            => sub { pod2usage(1); },
    ) or pod2usage(2);
    

    Where the value in the hashref is a variable reference, the value gets stored in there. Where it's a sub, that sub gets executed with the arguments passed in. That's the basics, and you don't have to worry about anything else. Your user can pass --abs instead of --absolute if it's unambiguous. You can have mandatory flags, as in agent=s, where --agent must take a string. On and on, it's probably got the functionality you need.

    One crucial reminder: You must check the return code of GetOptions. Otherwise, your program will carry on. If someone gives your program an invalid argument on the command-line, then you know that the program cannot possibly be running in the way the user intended. Your program must stop immediately.

    Not checking the return of GetOptions is as bad as not checking the return of open. In fact, I think I smell a new Perl::Critic policy....

  • ack 2.24 is released, speeding up common cases

    I've just uploaded a new version of ack, version 2.24, to the CPAN and posted it to beyondgrep.com.

    Read on →

  • Avoid the vagueness of dies_ok() in Test::Exception

    It's good to check that your code handles error conditions correctly, but dies_ok() in Test::Exception is too blunt an instrument to do it.

    Read on →

  • Dueling code wizardry is one of the things I love most about Perl

    At least week's Perl Conference, Damian Conway talked about some new magical awesomeness he created, as he so frequently does. It's Test::Expr, and it makes it easier to write tests:

    Read on →

  • Improve your test logs with simple distro diagnostics

    Automated module testing systems are becoming more and more common.  In addition to our long-serving CPAN Testers service, Perl authors can have their modules tested by Travis for Linux and Appveyor for Windows.  CPAN Testers tests each distribution uploaded to PAUSE, whereas Travis and Appveyor keep an eye on your GitHub account (or other services) and try testing after each push to the home repo.

    Read on →

  • Perl::Critic 1.128 fixes bugs and works with Perl 5.26

    I've just released a new official release of Perl::Critic, the static code analysis tool for Perl. It uses the new version of the PPI Perl-parsing module, and it works with the new Perl 5.26, which does not include . in @INC by default.

    Read on →

  • Perl::Critic releases its first new developer release in 21 months

    I've just released a new developer release of Perl::Critic, the static code analysis tool for Perl, as we work toward its first new release in 21 months. This version of Perl::Critic fixes a few bugs and relies on a new release of the underlying Perl parsing library PPI, which also has had its first new release in a while.

    Read on →

  • Speed up DBI reads by binding variables directly

    If you're using DBI directly for your database access, not through some ORM, then fetchrow_hashref is probably the handiest way to fetch result rows. However, if you're working on lots of rows and time is critical, know that it is also be the slowest way to do so.

    Read on →

  • ack 2.18 has been released; ack 3 starting development

    I've just uploaded ack 2.18 to CPAN and to https://beyondgrep.com/.

    Read on →

  • ack 2.16 has been released

    ack 2.16 has been released.  ack is a grep-like tool optimized for searching source code.  It's available at https://beyondgrep.com, or via CPAN using App::Ack.

    Read on →

  • Higher-level list utility functions with List::UtilsBy

    I’m in love with List::UtilsBy. It’s one of those “Why didn’t someone do this earlier?” modules (or maybe it’s “Why didn’t I know about it earlier?”). It replicates much of the functionality of List::Util and lets them operate on arbitrary blocks.

    Read on →

  • All about the new Test2 framework and how it will help your tests

    The new Test2 framework has been released after a couple years of development. I wanted to find out about what this means for users of Test::Simple and Test::More, so I chatted with the project leader, Chad Granum (exodist).

    Read on →

  • Template Toolkit's DEFAULT directive does not short-circuit

    Template Toolkit’s DEFAULT does not do short-circuit evaluation like you might think it would. If you have

    Read on →

  • ack 2.0 has been released

    ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.

    ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the "Why ack?" page for the top ten reasons, and dozens of testimonials.

    ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.

    • By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.
    • There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.
    • Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.
    • The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.

    On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.

    ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.

    A final note: In the past, ack's home page was betterthangrep.com. With the release of ack 2.0, I've changed to beyondgrep.com. "Beyond" feels less adversarial than "better than", and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.

    For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you've never used ack, give it a try.

  • Debunking the "five weekends every 823 years" myth with Perl

    Have you seen this bit of bunk posted recently? It goes like this:

    Read on →

  • Where can someone find Perl modules to contribute to?

    Bradley Andersen (his gmail username is bradley.d.andersen) wrote asking

    i am looking to try and contribute to perl and foss in general. do you know of a list of perl modules that are currently marked as 'maintainer died' that i might hijack, or, some list of module maintainers who may be looking for help? i am interested also in learning python and doing roughly the same kind of thing in that domain.

    Here are my suggestions, and I trust others will add suggestions in the comments:

    • First, pick a module that you actually use. The best module to work on is one that you already use. Check its bug queue, which will probably be at rt.cpan.org, but not necessarily.
    • Take a look at the ADOPTME user on CPAN. This is where orphaned packages go to live.
    • Check out 24pullrequests.com, a holiday-themed site of open source projects looking for help.
    • OpenHatch says it is "dedicated to matching prospective free software contributors with communities, tools, and education."

    Remember, not all contributions to projects need to be in the form of written code. There are plenty of ways to help out that work on the module tests and infrastructure, or don't require any coding at all. For some ideas, see my article 14 Ways To Contribute to Open Source Without Being a Rock Star".