Leon Timmermans

XS the easy way

2025-07-13T13:08:12Z

XS has a reputation for being hard to access and I think it's a shame because I don't think it has to be: it's mostly that the Perl API is hard. What if you offload as much logic as possible to perl, and use XS only to expose functions to perl? That would be much easier for a casual XS writer who doesn't know anything about Perl's internals.

So, in this example I will write a simple XS module for a real-life API, in this case POSIX real-time semaphores. This allows you to synchronize data between different processes or threads. At its core the API is this:

sem_t* sem_open(const char* path, int open_flags, mode_t mode, unsigned int value);
int sem_close(sem_t *sem);
int sem_unlink(const char* path);

int sem_wait(sem_t *sem);
int sem_trywait(sem_t *sem);
int sem_post(sem_t *sem);

]]> What's the simplest way to expose that through XS? That would look something like this:

#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include

MODULE = POSIX::Sem                PACKAGE = POSIX::Sem

TYPEMAP: <





sem_t *sem_open(const char* path, int open_flags, mode_t mode, unsigned int value)




int sem_close(sem_t *sem)




int sem_unlink(const char* path)




int sem_wait(sem_t *sem)




int sem_trywait(sem_t *sem)




int sem_post(sem_t *sem)


Let me explain. An XS file always starts with a C section, followed by one or more XS sections declared using the MODULE keyword.

Our C section is fairly short and obvious, I'm first importing all the Perl bits that we need, this is a boilerplate that every XS module will start with. Then we include the API we want to wrap (semaphore.h).

Then we declare we want to declare the POSIX::Sem XS module. This contains a typemap and a list of functions.

The typemap declares which conversion template should be used for specific types; it will already be predefined for standard types such as int and char*, but we do need to tell it that sem_t* should be treated as a basic pointer (T_PTR), and mode_t as an integer (T_IV). Typemaps are really useful for making your XS code simpler, but sadly they're rather underdocumented.

After that, all we have to do is declare the functions in XS as they're declared in C. All the code needed to wrap the functions up and export them into Perl will be automatically generated. 

Now we just need some Perl code to wrap it up:

package POSIX::Sem;
our $VERSION = '0.001';




use 5.036;




use XSLoader;
XSLoader::load(__PACKAGE__, $VERSION);




use Errno 'EAGAIN';




sub open($class, $path, $open_flags, $mode = 0600, $value = 1) {
    my $sem_ptr = sem_open($path, $open_flags, $mode, $value);
    die "Could not open $path: $!" if not $sem_ptr;
    return bless \$sem_ptr, $class;
}




sub DESTROY($self) {
    sem_close($$self);
}




sub post($self) {
    die "Could not post: $!" if sem_post($$self) < 0;
}




sub wait($self) {
    die "Could not wait: $!" if sem_wait($$self) < 0;
}




sub trywait($self) {
    if (sem_trywait($$self) < 0) {
        return undef if $! == EAGAIN;
        die "Could not trywait: $!";
    }
    return 1;
}




sub unlink($class, $path) {
    die "Could not unlink: $!" if sem_unlink($path) < 0;
}




1;


Here we use XSLoader to load the XS module and import the functions from the library. I could have chosen to leave it at that, but I chose to wrap it up in  a nice object-oriented API by storing the pointer that we get from sem_open in a scalar reference so I can bless it.. Other than that all the Perl code does is turn any error into an exception. The resulting API can be used something like this:

use 5.036;




use POSIX::Sem;
use Fcntl 'O_CREAT';




my $sem = POSIX::Sem->open("foo", O_CREAT);




$sem->post;
$sem->wait;


That's all folks!



A different Perl Toolchain Summit
2025-05-11T13:05:20Z
A week ago I attended the 2025 PTS. For me it was a different PTS than the previous ones.

Firstly because it was my first PTS without Abe Timmerman. He was a regular in both the PTS (as maintainer of Test::Smoke), and of the Amsterdam Perl Mongers. In fact the last time I saw him was on our flight back to Amsterdam after the PTS in Lisbon last year. He was greatly missed.

Secondly, because of a question that Book asked at the very beginning of the PTS: how often we had been to the PTS before. I was one of the few who had attended more than 10 of them. Combined with the fact that several other regular attendees couldn't make it that meant that this PTS I spent more time than ever on helping others with various issues.
]]>
        I also spent quite a bit of time in discussions. Most obviously on the future of the CPAN Security group that I joined last year. I also spent time giving feedback to the new CPAN Testers group, and talked with a bunch of people to get feedback on my idea to write a new CPAN client.

But obviously I also did a lot of programming work. I synced up a year's worth of updates on ExtUtils::ParseXS to CPAN (more changes are coming up from David Mitchell after 5.42). I released a new ExtUtils::Builder::Compiler (now working with Microsoft's compiler thanks to Mithaldu helping me out). I made ExtUtils::Manifest compatible with Test2::Harness/yath after someone (Breno?) pointed out it wasn't. I released a new App::ModuleBuildTiny with better configuration options after I sat down with Paul Evans to observe his release process. I fixed a minor issue in Dist::Zilla::Plugin::ModuleBuildTiny on older perls that Julien had pointed out to me. I worked on making Module::Build::Tiny's XS support more compatible with Devel::Cover after Paul Johnson pointed out that combination didn't work. I worked on making Test::Harness more asynchronous/parallel. I released a new Software::License and worked on improving PAUSE's password handling. And I updated experimental.pm for 5.42.

I spent a bunch of time investigating how to get TLS support into core. This is much more complicated than one might hope; partially because Net::SSLeay is a 29 years old large XS module (OpenSSL forked from SSLeay in 1998…), and partially because OpenSSL itself deeply depends on Perl in its build system. This is looking like it will be my next big project.

And I scared everyone by tripping on a ramp that got treacherously slippy in the rain. I didn't break anything. I think.

All in all I had a really useful PTS, even if I mostly did completely different things from what I had been initially planning.

All of this wouldn't be possible without our wonderful organizers (Daniel, Philippe, Laurent, Tina and Breno), as well as our sponsors:

Monetary Sponsors

Booking.com, WebPros, 
CosmoShop, Datensegler, 
OpenCage, SUSE, 
Simplelists Ltd, Ctrl O Ltd, 
Findus Internet-OPAC, plusW GmbH

In-kind sponsors

Grant Street Group, Fastmail, 
shift2, Oleeo, Ferenc Erki

Community Sponsors

The Perl and Raku Foundation, Japan Perl Association, 
Harald Joerg, Alexandros Karelas (PerlModules.net),  Matthew Persico,
Michele Beltrame (Sigmafin), Rob Hall, Joel Roth, Richard Leach, 
Jonathan Kean, Richard Loveland, Bojan Ramsa



An introduction to App::ModuleBuildTiny part 2: authoring
2025-03-21T22:09:37Z
Now that we have set up our mbtiny configuration in the previous post, we can actually use it.

Minting a new distribution

Minting a distribution is trivial once you’ve completed the setup. It’s typically just a matter of calling mbtiny mint Foo::Bar. If needed you can override the global configuration at minting time (e.g.  mbtiny mint Foo::Bar --license BSD).

Converting an existing distribution

You can also convert an existing distribution to App::ModuleBuildTiny. In most cases that requires just two things:
]]>
        
Delete the pre-existing Makefile.PL / Build.PL
run mbtiny config copy, to copy the global configuration into the local project.


Prereqs

Prerequisites can be handled in two ways. If the auto_scan option is enabled, dependencies will be automatically detected, usually that is enough. Alternatively, you can set them explicitly prereqs.yml or a cpanfile. E.g.


# prereqs.yml

runtime:
  requires:
    perl: '5.012'
    Path::Tiny: 0
  recommends:
    Term::ReadLine::Gnu: 0
test:
  requires:
    Test::More: '0.88'



It should be noted that App::ModuleBuild::Tiny will automatically inject a configure dependency on the build tool (usually Module::Build::Tiny).

Main subcommands

App::ModuleBuildTiny mostly tries to stay out of your way. Mostly you can just develop your module the way you’re used to, you just need 2-3 commands to start to become productive:

regenerate

Typically this is run right before the release of a new version. It will regenerate all files that need regeneration. It’s no coincidence that almost all of the previously mentioned configuration is about this subcommand, it truly is the heart of the application. What it does exactly depends on your configuration but in a typical case it would:


Bump the version in the module files
Scan for prerequisites
Scan the pod for the license / author
Gather all metadata.
Write Build.PL, META files, LICENSE, MANIFEST, etc…
Update Changes file for the new version.
Commit all of the above to git


If new to the tool you might want to do a git show before releasing, to better understand what it does, but in general it shouldn’t do anything surprising.

upload

This will do exactly what it advertises: creates a tarball for the distribution and uploads that to CPAN. Before doing that however it will do a series of preflight checks such as


Check if the Changes file contains entries for this release.
Check if the main module has an abstract in its pod.
Check if your module has a valid version that matches the one in the meta file.
Check if the desired version isn’t already tagged.
Check if all tests pass.


After these tests it will ask for final confirmation and then uploads to PAUSE.

test

In simple modules, you don’t actually need this subcommand, you can just use prove -l instead. That said, mbtiny test does two additional things that make it useful:


It does a fresh and full distribution build, allowing one to test XS modules or generated modules.
It will run author tests (e.g. xt/pod-syntax.t), and with --release will also run release tests.


Secondary subcommands

mbtiny provides much more than just the above three commands. The full list is documented in the mbtiny script but some honorable mentions are:

listdeps

This lists the dependencies. This is particularly useful after a regeneration with auto-scan, to double check if the list of dependencies is what you expect it to be.

config

This allows you to inspect and update the configuration of the local distribution.  You may need this to change your configuration, or to update it if configuration options have been added.

Choosing install tool

By default it will use Module::Build::Tiny, as its name probably had already given away. For the vast majority of people this will be the right choice as it can handle pure-perl and simple xs modules just fine. But if you need to use Dist::Build instead that’s easy: it will automatically switch if it sees a planner/ directory (that is what Dist::Build uses for its build scripts). More about that in the next blogpost!



An introduction to App::ModuleBuildTiny part 1: setting things up
2025-03-19T23:17:11Z
App::ModuleBuildTiny is a relatively new authoring tool. It aims to be a relatively lightweight (at least to some other tools like Dist::Zilla) and newbie friendly tool. It supports two install tools: Module::Build::Tiny (obviously what it was originally designed for) and Dist::Build; it does not support ExtUtils::MakeMaker or Module::Build.
]]>
        Installing

Installing is just a matter of installing the App::ModuleBuildTiny distribution using your favorite CPAN client.

A minimal setup

Before minting, it's advisable to have run mbtiny setup at least once, to set up a general configuration. It's not strictly required, but it will set a default configuration so you don't have to answer these same questions every time you mint a new distribution. If you don't care about the details, mbtiny setup minimal will have you set up in a minute with two unavoidable licensing related questions:


What is the author's name?
What is the author's email?


If you want a simple setup, that's all you need and you can actually stop reading the rest of this post.

A detailed setup

If you want more control, you can use mbtiny setup all to get all configuration questions. All questions have usable defaults. It adds one more legal question to the previous two.

What license do you want to use?

This defaults to Perl_5, the same license as Perl uses. If you've never given licenses much thought this is probably the best option for a perl module because this is what most of CPAN uses.

Writeback questions

These questions decide which files are written back to your filesystem/repository.

Do you want to write your build files to your filesystem?

If enabled, this will write Build.PL, META.json, META.yml, and MANIFEST files to disk when regenerating. If not they'll only be in the tarball. Enabling this is generally recommended as it makes CI workflows easier and enhances reproducibility.

Do you want to write your LICENSE file to your filesystem?

If enabled, it will generate and write a LICENSE file on regeneration (though usually it doesn't change after minting). This is usually what you want.

Do you want to write your README file to your filesystem?

If true this will generate a README file from the main module's pod. Unless you'd rather write your own README file you probably want to enable this.

Automation questions

These questions enable some extra magic that make mbtiny a little easier to use, but you don't actually need any of these if you don't want to.

Do you want mbtiny to automatically handle git for you?

This integrates automatic git handling. If enabled this will turn on flags on three commands


On mbtiny mint it will set --init-git to initialize a new git repository.
On mbtiny regenerate it will set --commit to commit the generated changes.
On mbtiny upload it will enable --tag and --push to tag and push the current commit.


I would generally recommend enabling this unless you're not using git. All of these options can be overridden the usual way (e.g. mbtiny mint Foo --no-init-git).

Do you want mbtiny to automatically bump on regenerate for you?

If enabled this will turn on the --bump option to mbtiny regenerate by default. In my experience bumping is the only time when you want to regenerate, but maybe someone wants to use a different workflow from mine.

Do you want mbtiny to automatically scan dependencies for you?

If enabled this will turn on the --scan option to mbtiny regenerate by default. This is similar to the [AutoPrereqs] plugin in Dist::Zilla. If you don't like this you can disable it and manually set your prerequisites using a cpanfile or a preqreqs.yml file.

Do you want mbtiny to automatically add a repository link to the metadata

This will try to automatically detect the right repository link for your distribution. Currently only github is well supported, patches for other git providers are welcome.

Do you want mbtiny to automatically add a bug tracker link to the metadata

This will try to automatically detect the right bug tracker for your distribution. Currently only github is well supported, patches for other git providers are welcome.

Changing things later

If you want to change things later, you call always call mbtiny setup all to go through the same questions again. Or use the setup set mode like mbtiny setup set auto_scan false.



A deep dive into the Perl type systems
2025-02-01T21:32:26Z
People usually don't think about Perl's type system. Some would even mistakenly claim it doesn't have one. It is, however, a most unusual one that doesn't really look like anything else.

What is a type anyway? And what is a type system? I'm not going to precisely define it here, that's for academics, but generally speaking a type is a fundamental property of a variable or value that determines what operations can and can not be done with it and what invariants it must hold. In a strong type system it is a stable trait: it can't change over the lifetime of the value/variable.

In some type systems containers are typed (such as C) and values really don't exist separate from containers. In other typed systems containers are typeless but values are typed (e.g. Python, Javascript, …). There are languages where both values and containers are typed (e.g. Java, C#), typically this means that the container constrains the values in it.

Contrary to what you might expect, Perl has the latter sort of typesystem, but with a twist.
]]>
        The Perl static type system

When you got up this morning you might not have expected to read that Perl is a statically typed language, but here we are. To be precise it is a closed, strong and statically typed language. There are exactly 7 types, all variables/values are exactly one of them, and they can never change into another type. Though only 5 of them are directly accessible so one could argue there are only 5 true types.

Scalar

Typically identified by the sigil $, this is the most famous type as it does most of the work. Almost all operations in the language work on scalars, it provides an enormous flexibility.

Arrays

Arrays are identified by the @ sigil. They're an ordered series of scalars, and support various operations typical of arrays such as indexing using the [] postfix operator, push, pop, splice, … that all do what anyone would expect from them.

Hashes

Hashes (also known as maps, dictionaries or associative arrays in other languages) are identified by the % sigil. They're an unordered mapping of string to scalars. Its values can be accessed using the {} postfix operator, and it supports the expected operations for a mapping: keys, values, delete, exists, etc…. Like arrays they work more or less the same as they do in other dynamic languages.

Subs

Also known as functions. They have a sigil (&), but they are omitted when defining them (sub foo {}) and usually also when calling the function (foo(1) versus &foo(1)). These values can't be used to access these values directly; the only thing you can really do with it is to call it. Instead you might encounter these values as a reference to a sub.

Globs

The last type to actually have a sigil (*) are globs. This is probably the most confusing type as it's unique to Perl. A glob contains its own name, as well as one of each other sigiled types  (scalar, array, hash, sub) and two opaque values: io and format. The symbol table is essentially a hash of globs. So a package variable @Foo::bar can also be accessed as @{ *Foo::bar{ARRAY} }. Much of this is vestigial behavior from perl version 4 and older, and unless you're hacking the symbol table you should have no need of messing with them.

IOs

These contain file handles. They have no sigil and can only really be used opaquely through their glob (or via a reference, but no one does that). All operations on them are typically done through that glob (or a reference to such a glob). They support various operations that you'd expect from a file handle (e.g. readline, printf, …).

Formats

Formats are another unique type in Perl. They're a special kind of sub that is attached to an IO via the glob, used via the format keyword. You're probably better off knowing as little as possible about them.

Common operations

All sigiled types can be used with the referencing operator \ (e.g. my $foo = \&function). All accessible types can be used in both scalar and list context (e.g. scalar(@array) will return the number of entries in the array), and @array = %hash will return a list of alternating keys and values); some would consider that type weakness. All accessible types can be used as arguments to functions (though that usually means list context). Other than that there are no operations common across all types.

The dynamic type system

Of course, none of the above is what you were thinking of when I first said type system. What you were probably thinking about was types of scalars. Once again, this actually works differently from other systems.

Fundamentally though, there are only 7 operations you can do on scalars, all the others can be composed of them.

Primitives

Firstly there are the three primitive conversions:


Get an integer value.
Get a floating point value.
Get a string value. This value might be internally latin1 or utf8, this should not matter to the language; when it does that is known as The Unicode Bug.


All scalars are usable as integers, floats and strings, this is a fundamental trait of the scalar type. If any scalar is lacking any of these, the missing primitive will be generated from one of the others (e.g. float from int, int from string). It might give a warning because it's unhappy about those conversions (e.g. «Argument "a" isn't numeric in addition»), but it will continue nonetheless.

This is why perl has two sets of comparison operators (e.g. == versus eq), and a concatenation operator (.) separate from addition (+). Perl puts that polymorphism in the operators instead of the values. When people complain that perl is weakly typed they usually complain about this triple valuedness. I'd argue it's not weakly typed, just unusually typed.

Assignment

Any scalar can be assigned to. This replaces the value entirely. In reality of course there are various mutating operations for efficiency reasons, but conceptually the model doesn't actually require mutators; creating a new value and assigning it to the old should always be equivalent to mutating the old.

Definedness

Any scalar can be either defined or undefined. An undefined is a value that doesn't have any primitive value. As such, you can do nearly nothing without it warning warnings, other than checking definedness.

Package lookup

Package lookup what's used by method invocation(-> and the isa operator (since perl 5.34)) to determine what class should be used for method calls on a scalar.

Dereferencing

Dereference it. There is a dereferencing operator for each of the 5 sigils (e.g. @{ ... }; values may support any subset of it (including all or none).

That's it

Literally all scalar operations in Perl can be composed out of combinations of these. E.g. numeric operations like + will numify their operands and create a new numeric scalar. An operation like print will take the string value and print that to the handle.

Subtypes

As I said before, Perl is polymorphic on operators not on values; it will generally use the appropriate value for that operation. That said, some values consistently behave differently from other values, and can be thought of as a subtype for that reason. Any value is strictly one of these three subtypes, and it can't change its subtype without an assigning/mutating operation to that variable.

References

A references are indirections to a value of one of the 7 basic types of the language, or in recent perls potentially other opaque types (e.g. regexes or the new object representation in feature class). They will numify to an integer representation of their address (e.g. 0x57b6255ae580) and stringify to something derived from that (e.g. "ARRAY(0x57b6255ae580)"). They are always defined, and how they invoke and dereference is dependent on the value they refer to.

Only the dereferencing operator matching their referent's type is allowed, this ensures type-safety; trying to use any of the other 4 will throw an exception. Dereferencing isn't allowed for types that don't have a sigil (IO, format and opaque types).

Method invocation on references is only allowed when its referent is blessed (a lot of documentation suggests it's a trait of the reference itself, this is incorrect). Any type of value can be blessed (even formats, though some would call that cursed instead). A blessing is literally nothing more than tagging a value as belonging with a specific class. On method invocation, the method is looked up using that class as its starting point.

Blessed references can support operator overloading for both primitive operations and dereferencing. 

Fake globs

Fake globs are essentially a vestigial feature from perl4, I don't even think they're even documented. They work sort of like references to globs, except they will accept all dereferencing operators (and use the appropriate glob slot them for). It will stringify to the glob's full sigiled name (e.g. "*Foo::bar") and are always defined. I think you can work with Perl for decades without ever encountering or needing any of these, but they exist in weird corners.

Other

Anything else is other. Other values may contain any combination of the three slots: integer, float and string (e.g. (1.0, "1")). Usually the values logically match with each other, but that does not necessarily have to be the case (most famously in $! they do not). An undefined value is any value that has none of these three set; it's equivalent to (0, "") except it will warn when used as either of them. These are the only values for which the defined operator returns false.

If use strict (or actually use strict 'refs') is not enabled, these values can be used with any of the dereferencing operators for symbolic dereferencing (e.g. @{ "Foo::Bar" }) using their string value. When strict is enabled (they should be in 99.9% of all code) symbolic lookup is forbidden.

The dynamic type system, level two

Of course, none of the above is what you were thinking of when I first said type system. What you actually want to think about is objects.

One of the issues with calling this a type system is that it's actually mutable, which suggests it's a weak type system at best, but you can just easily argue it's part of the value instead of the type. We treat it as if it's a strong type because people don't actually rebless objects; the only exceptions I know of are cases where an object is reblessed into a subtype (e.g. upgrading an IO::Socket to IO::Socket::SSL), which is just sensible enough to not break people's Liskov expectations.

Fundamentally Perl's OO-by-blessing is one of the most minimal OO systems that has ever been invented (though). With just blessing and the method call operator it gives us useful types; but it doesn't really give much a system. 



Using peppers with Crypt::Passphrase
2024-02-11T17:50:41Z
Crypt::Passphrase

Crypt::Passphrase is a module for managing passwords. It allows you to separate policy and mechanism, meaning that the code that polices authorization doesn’t have to know anything about what algorithms are used behind the screen, and vice-versa; thus making for a cryptographically agile system.

It’s not only handling the technical details of password hashes for you but also it deals with a variety of schemes. It’s especially useful for transitioning between them.

A configuration might look like this (Koha):
]]>
        
my $auth = Crypt::Passphrase->new(
    encoder => {
        module => 'BCrypt',
        cost   => 8,
    },
    validators => [ 'MD5::Base64' ],
);


Using it might look like this:

if (!$auth->verify_password($password, $hash)) {
    die "Invalid password";
}
elsif ($auth->needs_rehash($hash)) {
    my $new_hash = $auth->hash_password($password);
    ...
}


It supports a variety of algorithms, but argon2 and bcrypt are by far the most popular ones. That said, it can do much more that that: it can do peppers for you.

Why Peppers

The function of peppers is to protect leaked passwords, especially the bad ones. Password hashes try making brute-force attacks so expensive that attackers won’t even bother, but in the end they can’t really protect passwords from a dictionary attack. The key-space of bad passwords is so small that you can’t really prevent that.

When you add a pepper, that means an attacker needs to brute-force both password and pepper, but because the pepper doesn’t need to be memorized by a human it can actually be a piece of high-entropy (e.g. a 16 or 32 byte chunk of good randomness). That would make it well outside of reach of any brute force attack for sheer physical reasons.

The most important thing you must understand about peppers is that like passwords the security they provide hinges entirely on their secrecy. If that secrecy is compromised they don’t do anything for security. If you remember nothing else of this blog post, please remember that.

Mapping Peppers

The first thing you’d probably notice about my modules is that you don’t pass it a pepper, but a map of peppers. This is an essential quality of the system that a lot of naive pepper implementations are lacking. Peppers are keys, and all keys must be rotatable. Like passwords, you need to be able to change them if they may have been compromised. By using a map and adding the identifier in the metadata section of the hash, you can rotate in a new key while still able to check old ones. This gives the system the agility it needs to …

Style of peppers

The second thing you might notice is that I provide two very different styles of peppering; using some sort of MAC before the password hash, and using symmetric encryption after the password hash (e.g. Crypt::Passphrase::Argon2::AES and Crypt::Passphrase::Bcrypt::AES). The former approach appears to be more common out in the wild, but that latter is by far the better one. Firstly because its security is easily provable (it hinges only on symmetric encryption, not on an unusual combination of constructs), but secondly because it allows for easy re-peppering without needing the user’s password to recompute the password hash inside of it (essentially just decrypting with the old key and encrypting with the new one). For that reason I would strongly recommend the latter approach.

Using peppers

It can be as simple as this:

my $auth = Crypt::Passphrase->new(
    encoder => {
        module => 'Argon2::AES',
        peppers => \%peppers,
    },
);


All you really need to do is change the module name and pass in the peppers. The hardest part of it is probably securely storing the peppers. There are many tools to help you with this (e.g. vault, sealed secrets, and/or my own Mojolicious::Plugin::Credentials). How to best do this really depends on your setup.

Arguably the best option is using a hardware security module (e.g. CP::Argon2::HSM), but few people has a hardware security module laying around (good ones are rather expensive, though you might convince your TPM2 to function as one).

TL;DR

Using peppers doesn’t have to be that hard. If you have an appropriate credentials store, you can easily add it to your application and enhance the security of your passwords. Maybe you too should give Crypt::Passphrase::Argon2::AES a try.



My 2023 in Perl
2024-01-23T17:30:02Z
2023 was a rather productive year for me on CPAN. Aided by taking some time off I managed to release a whopping 18 new modules.

Passwords


Crypt::HSM
Crypt::Passphrase::Argon2::AES
Crypt::Passphrase::Argon2::HSM
Crypt::Passphrase::Linux
Crypt::Passphrase::Pepper::HSM
Crypt::Passphrase::Yescrypt
Crypt::Yescrypt
DBIx::Class::CryptColumn
Mojolicious::Plugin::Passphrase


Half of my new modules were related to my password framework Crypt::Passphrase. To be honest most of them are either small (± 100 LOC) glue two or three other pieces of code together. And then there was Crypt::HSM, a PKCS11 interface (to use cryptographic hardware without exposing cryptographic keys) that was probably more work (2600 LOC of XS) than the others combined.

Most of this was with the aim to add peppering support to Crypt::Passphrase, a subject extensive enough that I should probably dedicate a separate blogpost to it.
]]>
        Typemaps


App::typemap
Dist::Zilla::Plugin::Typemap
ExtUtils::Typemaps::Magic


ExtUtils::Typemaps::Magic contains a set of typemaps that help me write XS based objects. In particular the MagicExt typemap allows me to write thread-safe objects (in my particular case: refcounted), which no built-in typemap does. App::typemap helps one integrate typemap bundles into your local typemap file, and Dist::Zilla::Plugin::Typemap does the same for dzil.

Toolchain specs


CPAN::API::BuildPL
CPAN::Static


I finally got around to publishing two pieces of toolchain that had been in the pipeline for years. CPAN::Static contains a specification and reference implementation for static installation of modules in CPAN clients. For 90% of all dists, ExtUtils::MakeMaker and Module::Build are an overkill and all they really need is to copy some files and run tests. 

CPAN::API::BuildPL, a specification for Build.PL implementations was mostly written by David Golden but never got published, but now CPAN::Static depends on it so was published alongside with it.

Other


Magic::Check
Magic::Coerce


These two modules add a little typing to Perl. Magic::Check implements runtime (type) checking on a variable, and Magic::Coerce implements coercers. They're both really more low-level backend modules that beg for a wrapper with a better syntax that I haven't come up with yet.


Thread::GoChannel


This module brings Thread::CSP style channels to threads.pm as an alternative to Thread::Queue. As its name indicates, its semantics are close to that of Go channels, instead of the more asynchronous behavior of Thread::Queue.


Syntax::Infix::Smartmatch


This is an implementation of a simpler and more predictable kind of smartmatching than the one that comes with core. It's intended to be usable even if smartmatching gets removed from core itself.

Conclusion

I had a productive year, and some pretty good leads to move forward this year. I'm looking forward to it.



Some tricks for prettier xs
2022-02-20T11:52:01Z
XS has a reputation of being ugly and cumbersome, but in my experience, it doesn't have to be. Let's take for example this snippet from my Thread::Csp::Promise class:

MODULE = Thread::Csp PACKAGE = Thread::Csp::Promise PREFIX = promise_

SV* promise_get(Promise* promise)

bool promise_is_finished(Promise* promise)

SV* promise_get_notifier(Promise* promise)

]]>
        How did I write XS with so little code/boilerplate? By using XS the way it was originally intended: to glue Perl and C together, not to implement any behavior.

No CODE
A lot of people seem to think you need a CODE block in your XS functions, but often you don't. For example 
SV* promise_get(Promise* promise)

is actually equivalent to 
SV* promise_get(Promise* promise)
CODE:
    RETVAL = promise_get(promise);
OUTPUT:
    RETVAL

By giving the `promise_get` function the right shape and name, I don't need to write any of that.

This doesn't only mean less code (which is always good), it also means that it's much easier to split a large amount of code into multiple files, as doing this in C is much easier than doing it in XS (e.g. DBI.xs is 5700 lines). This aids in making your project more maintainable.

No K&R
The second thing you may notice is that I'm declaring the types of the arguments in ANSI style (within the parentheses), not the common K&R style like:
SV*
promise_get(promise)
    Promise* promise;

The author of perlxs and perlxstut was clearly fond of K&R style, and everyone seems to have copied it from the documentation, but ANSI style is far more familiar to most people, and less repetitive. While the K&R style can do a few things ANSI style can't (e.g. with regards to custom conversions), it's very uncommon to need any of that.

Typemaps
To convert from arguments from Perl values to C values, and vice-versa for the return values, I used type maps. 

TYPEMAP
Promise* T_PROMISE

INPUT

T_PROMISE

        $var = sv_to_promise($arg)

OUTPUT

T_PROMISE

        $arg = promise_to_sv($var);



Using these templates, you don't need the XS or the individual functions to worry about type conversions for the most common argument types.

Prefix
All the XS packages in my module are defined with a prefix:
MODULE = Thread::Csp PACKAGE = Thread::Csp::Promise PREFIX = promise_

That way I can namespace my C functions to all start with `promise_`, but on the Perl side promise_get will be a sub called get (in the package Thread::Csp::Promise).

C_ARGS
I still had one function where the default glue code didn't quite cut it, because that had a slurpy argument so I couldn't map arguments 1-on-1. Instead of using a `CODE` block here, I used the C_ARGS to override only how the arguments are passed from Perl to C, without overriding any of the rest of the code generation. And then I defined a helper that turns the arguments on the stack into an array that is passed to the function.
Promise* thread_spawn(SV* class, SV* module, SV* function, ...)
        C_ARGS:
                slurp_arguments(1)



My new modules in 2021
2021-12-29T14:29:16Z
Perl

I had a reasonably productive year, releasing several modules that I think/hope are useful for the wider ecosystem.

Crypt::Passphrase

This module manages the passwords in a cryptographically agile manner. That means that it can not only verify passwords using different ciphers, but it also aids in gradually upgrading passwords hashed with an outdated cipher (or outdated settings) to the current one; for example when you want to upgrade from bcrypt to argon2. Password hashing is both a rather common form of cryptography, and one that is more subject to change than others; you should probably reevaluate your password handling every couple of years. With this module, you can initiate such a transition with a simple configuration change.

This also includes a number of extension distributions (e.g. Crypt::Passphrase::Argon2, Crypt::Passphrase::Bcrypt, etc…), and one new backend module (Crypt::Bcrypt)

Thread::Csp

My most ambitious project of the year by far. It's actually been in the making for a decade, full of lessons learned in my previous attempt. Thread::Csp is a new threading library (build on ithreads primitives, but not on threads.pm and doesn't clone whole interpreters); it is based on Communicating Sequential Processes (hence the name), the same model that Go uses (in particular for its channels).

I firmly believe share-nothing message-passing models of multi-threading are the overlap between what is useful and what is realistically possible given the current interpreter.

autocroak

This is essentially an autodie replacement with one important difference: it's based on opcode overrides instead of function overrides. This means not only that it interacts better with other pragmas, but also that it can support keywords that can not easily be overriden (such as print and system). It should also give less weird edge-cases than autodie.

Raku

I didn't produce as much Raku code this year, most of my Raku energy went into writing a series of blog posts that eventually I made a conference presentation instead.

Crypt::Passphrase

This was a port of the previously mentioned Perl module. It doesn't quite have the backend ecosystem that its big brother has, but given that there's a lot less legacy software in Raku that's not all that much of a problem.

Net::MQTT

A friend complained about the lack of MQTT support in Raku, and binary protocols just happen to be something I have a lot of experience with, so I implemented an MQTT client. While arguably this is the least useful module of the bunch, it was the most fun to write. Raku's typesystem and integrated event loop made this experience a lot smoother than they would have been in other languages.



The Witch and the Witch-hunt
2021-05-23T20:51:52Z
A lot has been said about the recent CAT report and updates. It feels to me like we're not getting anywhere because the critical matters aren't being addressed.
]]>
        Division

Right now there are two groups of people with opinions on this matter.

One group is appalled by the original report, because they have a number of serious concerns with the report. There was


A truth-seeking process that was haphazard at best, in ways that are obvious to anyone with the slightest bit of knowledge of what happened
An expeditionary power-grab despite explicit requests not to do so
A punishment that was clearly not proportional to the incidents described
A willingness to cherry pick people from one side of a conflict where both sides have behaved in ways they really shouldn't have.
An apparent willingness to punish people who associate with Subject


Combined this means that people fear the CAT because this is exactly the sort of behavior that can easily result in innocent people being banned.

The other group was relieved that someone they have known to be toxic is finally being removed from the community. Most have had so many negative experiences with him that they'll readily believe any further accusations in his general direction without need for further evidence. Others genuinely don't care anymore how the sausage is made as long as he's eliminated from the community.

These different worldviews make it almost impossible for people to talk about the issue at hand, because they're talking past each other. Almost any discussion on the subject quickly devolves to bickering between people saying "How can you defend this toxic person" versus people saying "how can you defend this miscarriage of justice". For a lot of people it becomes a "you're either with us or against us" type of issue. Without splitting these conversations, we can't actually meet each other eye-to-eye. One can admit that what happened here was a cockup without denying that it tries to deal with an actual issue.

Accountability

Simply put, it rather appears like the CAT is firmly in the second camp. Everything that happens makes sense if they already believed him to be toxic and this incident was an opportunity to kick him out for once and for all. I'm not saying this was a conspiracy or some such; I'm suggesting that they were sufficiently biased that they got sloppy in dealing with this incident, they were entirely caught off guard by opposition to what they had done. The thing is, the CAT should not be doing a witch hunt, even if we know the target to actually be a witch.

The CAT's (draft) charter says "the CAT must be trusted and viewed as consistent and impartial" and "to maintain the trust of the community, the CAT must make its processes and actions transparent while not sacrificing privacy" but right now a large segment of the community doesn't trust them anymore because they have failed to do exactly those things. Despite all their good intentions, the CAT's actions actively worked against those intentions by focusing on the "easy win" and made the situation more difficult the next time action needs to be taken.

The CAT is supposed to enforce accountability in our community, but it can not credibly and effectively do that if it is not accountable itself. What TPF should have done IMHO is pull the report and let someone else redo the entire thing, but it's probably too late for that now. What they can still do to put our community on a path out of this conflict is for them to:


acknowledge what they did wrong
answer the question "how could this have happened?"
apologize for it


but from my conversations with them over the past five weeks it rather looks like they intend to just move on without doing any of those things.

Closure

We've been infighting for a full year now, for a brief moment between the PSC's use v7 announcement and the CAT's report it seemed we might finally get some peace. The CAT clearly underestimated just how divisive this action would be, and more division is the very last thing our community needs right now. This is the thing that upsets me the most of all; I remember a few weeks ago telling myself "finally we can put all this drama behind ourselves", I even wrote a blog post with that perspective and quite the opposite has happened.

I am tired of conflict and very disappointed.



Perl7 is a fork of values
2020-08-01T11:28:46Z
Before reading this, you should watch this video where Bryan Cantrill explains a value-conflict between Joyent and Node.js, I believe we have a similar problem.

In it he defines a list of project values:



All these values are important - but they are in tension. In the end one has to choose between them.

Perl's has traditionally prioritized certain values over these others, and in my experience these are:


Expressiveness
Extensibility
Stability

]]>
        Expressiveness is probably the most obvious one.

Extensibility is probably less obvious, probably because it was less of a concious choice, but feels like the right pick for a language that has several OO frameworks and custom keywords.

Stability, in particular backwards compatibility, is thoroughly embedded in our policy document:


  Lately, ignoring or actively opposing compatibility with earlier
versions of Perl has come into vogue. Sometimes, a change is proposed
which wants to usurp syntax which previously had another meaning.
Sometimes, a change wants to improve previously-crazy semantics.

Down this road lies madness.

...

When in doubt, caution dictates that we will favor backward
compatibility.

...

Using a lexical pragma to enable or disable legacy behavior should be
considered when appropriate, and in the absence of any pragma legacy
behavior should be enabled.

...

No matter how frustrating these unintentional features may be to us
as we continue to improve Perl, these unintentional features often
deserve our protection. It is very important that existing software
written in Perl continue to work correctly.


More than any other major scripting language, we value keeping code working. Where other similar languages (especially Python) are breaking relatively common constructs regularly, we generally tried to limit that to the margins (though there's certainly some breakage in any major release).

That doesn't mean all subcommunities share exactly the same values though. I'm involved in the toolchain, and in the toolchain we have very specific values:


Robustness
Portability
Stability


These are the values of sysadmins. Environments where working things have to keep working.

Whereas for example the Mojo community generally seems to prioritize


Approachability
Expressiveness
Velocity


These are the values of modern web development, where change is the only constant.

And mostly, that difference is fine. It helps a lot if a community's values overlap with the language values, but different communities can have different values without biting each other.

That said, Perl has been having an internal conflict over its values and where to take the language itself. This tension has existed for several years now, and is focused primarily around stability. The primary axis of tension is approachability versus stability.

Simply put, should new features and defaults be guarded by a version or feature guard (e.g. use v5.34 or use v7) (stability), or should they be enabled by default in the next perl version (approachability). 7.0 doesn't aim to bring new features, it doesn't enable us to do anything that isn't possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability.

The crucial thing to realize here is that that means that perl7 is not just a fork of the interpreter, it is also a fork of our community and our ecosystem. To some extent that fork can be postponed until perl8 drops perl5 compatibility, but given this new course it is inevitable. Some will join this brave new world, and some will not.

To make this fork of values complete, even the values of governance are completely different. Where perl5 had perl5-porters, a mailing list that was open to the entire community (and historically perhaps a bit too open), perl7 has a steering committee whose membership is invite-only and that only posts summaries of its activities to p5p.

And while everyone is wondering where perl7 is going, the other crucial question is where perl5 is going; will it stop where it is now (the current official plan), will there be a 5.34 (something I have repeated argued for because it makes no sense for the sunsetting release to have experimental features, and is lacking a perl5 executable out the box), will perl5 development continue as it did before? This is something that isn't talked about much and I'm not sure yet what will happen, but I am pretty sure that decision shouldn't be taken by the people who don't want to use it.

I don't know where we're going. I'm not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn't). And that terrifies me.



Perl 7, not quite getting better yet
2020-06-24T20:50:30Z

  Hegel remarks somewhere that all great world-historic facts and personages appear, so to speak, twice. He forgot to add: the first time as tragedy, the second time as farce.

The Eighteenth Brumaire of Louis Napoleon - Karl Marx


Sawyer just announced his plans for perl 7. And while Perl 7 sounds like a lovely language, I do see a number of issues:

Cohabitation / Forking

The proposal is presented as a linear progress, I don't believe this is realistic. This would be fork much like the python 3 transition is (which also wanted to be a simple linear progression). As we all know, they're currently in year 12 of a 5 year transition.

There are several problems here. CPAN as an ecosystem is the one that is given most attention to (not without reason; it is without doubt the most important collection of Perl code), but it's not even the biggest problem.

The biggest problem is that /usr/bin/perl is infrastructure. We can't do breaking changes to its basic functionality for the same reason that shell and awk can't. Too many things in too many places are dependent on it, from system administration scripts to bioinformatics workflows to build systems (e.g. autotools, postgresql) and many more.

And this change is vastly breaking. Enabling strict and disabling prototypes (to make way for signatures) will break vast amounts of code, especially in the scripting domain of perl.
It's quite telling that 12 years after python3 was released /usr/bin/python isn't a python3 by default on any of the big distributions (Ubuntu, Debian, Fedora, Red Hat, OpenSuse); and arguably python is less entrenched than perl is. I don't believe that /usr/bin/perl will ever be perl7. That means that perl7 can only meaningfully exist if it's set up to coexist alongside of perl5 for a very long time. And that actually comes with a number of challenges that may not seem obvious at first (e.g. colliding script names and man pages).

Releasing a Perl7 will not erase perl5. Perl5 will in all likelihood remain the Perl that's available on any platform regardless of how successful perl7 will be.

Perl 8 and beyond

Major version transitions are costly, and often traumatic (Perl 6 and Python 3 being obvious examples). Communities also take a lot of time catching up with them (again, see above examples); at least a decade if not more.

A big, breaking release is something a mature programming language can only do once per decade or so; anything else would result in two transitions going on at the same time. We shouldn't even be thinking about a perl8 this decade, let alone a perl9. If we are to do a perl7, we must get it right the first time. And I don't think this plan is quite getting it right.
And quite frankly, I can't imagine any reason for wanting to do a big breaking release if we'd do 7 right.

We are not ready

The current plan is essentially Enable all non-controversial features by default, and I don't think that that is the best we can do. There are a lot of features that haven't been implemented before because they don't make much sense in a minor release (in particularly the kind that removes syntax like no feature 'indirect'). Releasing it now will force a perl8 relatively soon, and that would be undesirable for all the reasons stated above.

Manpower

We have been failing at shipping non-experimental signatures for more than half a decade now, why would we be able to ship a perl 7? The most significant new feature that made it out of experimental in the past half decade was postfix dereferencing, and while welcome it's not quite a game changer.

Sadly, the most convincing reason not to go through with this may very well be "we may not be able to". I think we need to figure out what problems we can resolve before deciding to actually go forward with this.

Timescale

There's just no way we can do all of the above before the end of the year for a variety of reasons. Not only because it will require adaptations on the perl5 side to enable cohabitation, but also because we will need to sort out a lot of details. Trying to rush is likely to result in a failure, and is not something we can afford. I can't imagine any way of successfully doing this that doesn't involve releasing a v5.34 first (and possibly more).

Then don't upgrade?

The if you don't want your code to break then don't upgrade argument is rather assuming users have a firm control over which perl they are running. This is generally true for million line perl web applications, but this is not true for system perl.

If our objective is to limit ourselves to perlbrew/perlbuild/etc…, many of my objections become moot. But I don't think that should be the target, I think that would exclude a wide range of applications. So no, I don't think saying "then don't upgrade" really solves that problem. We may be able to postpone the problem, but it won't go away by itself.

The absentee/maintainer dichotomy

I do not recognize this distinction at all. Just because I actively maintain my stuff doesn't mean I want to be dealing with other people breaking my code. If I wanted to deal with the whims of a platform breaking trivial things I'd be programming python.

Associating not wanting the language to break with diminishing use of the language is perplexing to me. Perl is a language of which a lot has been written already, and relative to that past popularity not all that much new code is being written. Quite a lot of Perl strongholds are attributable to Perl not breaking, it's uncertain if the pain of this process will be worth the gain.

There's also this suggestion that people who care about backwards compatibility contribute less to the language. This isn't actually explained further but it seems like a rather bold statement to me.

Whom are we serving?

Perl has many different types of users, with many different needs. This is inherent to a language that tries to be useful at 1 line and at 1 million lines.

The argument that has been made in the keynote suggests that the only reason why one would use "old-style Perl" is because you've abandoned your code, and I don't think that is true. Many best practices that are essential when writing large applications are not nearly as valuable in a small script; it would be outright silly to suggest one-liners need strict.

The changes that are proposed are largely serving the manipulexity end of the spectrum. And this is an important user base, but it's not our only user base. For the whipuptitude end of the spectrum, the scripters, this represents their code breaking without them getting anything in return. That is the priority that is being chosen here.

Bad code

I believe this "bad pattern" rhetoric is flawed. Ultimately the only good code is working code, and the only bad code is code that doesn't get the job done. What I hear being described as bad code is actually merely ugly code. And this transition can break stuff for people, and breaking code is bad, whereas ugly code is only a problem to me if it ends up on my plate.

How did we get into this brave new world where one calls judgment on users and deplatforming the ones deemed bad?

This reminds me of a bioinformatician I met at a recent TPC. Was their code strict? No. Did it get the job done? Yes. Why would they care if we in the echo chamber approve of her code, they have more important things to do, like curing ovarian cancer. In my book, they got their priorities straight.

Is this really worth it?

This seems like a lot of pain, just to avoid having to type use v5.32. The real problem of course is that that doesn't only not enable warnings (which we can easily fix for 5.34), but it also doesn't enable signatures (probably the recent feature people care most about). If we can make use v5.34 do those two things, I don't think I need a perl7, even if I understand why some other people feel they do want it. Boilerplate may be annoying, but one line of boilerplate in every file is way more tolerable to me than the pain of a fork.

This was Jesse Vincent's vision 9 years ago, and I still think this is the right trade-off for a platform like Perl.



Smartmatch in 5.27.7
2017-12-23T13:24:34Z
What happened?

In the latest development release of perl, smartmatch changed quite a bit.

Almost everything you believed about smartmatching is now wrong

No really, everything. All previous rules are gone except a single one: you can smartmatch against any object that overloads smartmatching (the only "objects" that overload them out of the box are qr// regexps).

Matching against a scalar value? Gone. Matching against a list of values? Also gone.

when is no more.

The when keyword is gone, split into two keywords: whereis and whereso; one smartmatches the value against the current subject and the other does a simple boolean check much like if. I'll let you guess which is which. This split is for good reasons (when sometimes does one and sometimes the other, sometimes depending on things like optimizations), but that doesn't make this any more intuitive.

use 5.010/use 5.028 won't guard you from this.

It would have been possible to support both behaviors, because the old behavior is already using feature.pm. In fact one could even enable old and new style when at the same time in a scope without problems. None of this was done though.

My suggestions

new smartmatch should be more useful.

Right now one can't do anything with it without a helper library (like my Smart::Match). That's just silly.

The insanity of old style matching was that the overloads depended on both operands, this gave rise to hard to predict behavior, but that doesn't mean one can't define useful behavior that only depends on the right side that follows the most common use-cases. In particular matching scalars stringwise, and making $foo ~~ ["bar", "baz" ] mean $foo in [ "bar", "baz" ].

This should be opt-in

Despite retroactively adding warnings the feature is experimental, it has become a widely used feature. This change is breaking a (yet unknown but significant) number of CPAN modules, and likely much more code in darkpan. Breaking this unless strictly necessary is dumb.

And it isn't necessary. We can easily only enable the new behavior when asked for. That way we can improve smartmatching without breaking a decade worth of smartmatching code.

We need better words

whereso and whereis are way too confusing. I'm not sure what that would look like but this just doesn't cut it.

Above all, we need a better process

Somehow, p5p made a fundamental breaking change to the language without even trying to involve the wider community. This blogpost shouldn't have been the first time the wider community hears about it. And we need that wider community IMHO because no one on p5p (myself included) has the kind of language design talent that's required to do the sort of thing we did here. I don't know what the solution would look like exactly, but I like this process even less than I like the outcome so far. I must admit I'm somewhat jealous of Python's PEP process, though I'm not sure that would work without a language designer to guide it.



File::Slurp is broken and wrong
2015-08-18T11:54:05Z
If you are using File::Slurp, you should possibly reconsider. Basically, there are three reasons to do so;

It is wrong in a lot of cases.

File::Slurp predates IO layers, and as such doesn't take them into account well. A few years ago, after some complaints, an attempt was done to make it handle encodings. This was nothing short of being wrong.

The best known bug in this area is #83126, which means that :encoding() layers are always interpreted as :utf8. This not only means that UTF-8 encoded text is not validated (which can be a security risk), but also that files in other encodings (such as UTF-16) will be read as UTF-8, which surely will give an incorrect result.

Likewise it's not handling :crlf correctly, in particular explicitly asking for :crlf will always disable it, even on Windows.

Basically, it's doing all binmodes wrong except the one you shouldn't be using anyway (:utf8), and you should pretty much always be using a binmode, so there's no way to win really.

The interface is poorly huffmanized.

Huffmanization is the process of making commonly used operations shorter. File::Slurp is failing to huffmanize in the unicode world of 2015. Text files are usually UTF-8 nowadays, which in File::Slurp would typically be read_file($filename, binmode => ':raw:utf8'). The shortest option, read_file($filename), does something that most people don't really want anymore: latin-1 encoded files with platforms specific line-endings.

This is mainly the fault of perl itself (backwards compatibility is a PITA), but a library can work around this to make the programmers life easier.

It is poorly maintained

The critical bug mentioned above has been known for about two years, yet the author hasn't even bothered to respond to it, let alone fix it. There hasn't been a release in 4 years despite an increasingly long list of issues. Worst yet, this isn't the first time such a thing happens; before his last maintenance surge in the spring of 2011 the author was also missing-in-action for years. This negligence is inexcusable for a module that is so commonly depended upon.

Recommendations

Instead of File::Slurp, I recommend you use one of these modules depending on your needs:

If your needs are minimal, I'd recommend my File::Slurper. It provides correct, fast and easy to use slurping and spewing functions.

If your needs are average (which is the case for most people), I'd recommend Path::Tiny. This provides a well-balanced set of functions for dealing with file paths and contents.

If you want to go for maximal overkill, try IO::All. It will do everything you can imagine and more. 



QA Hackathon 2013
2013-04-15T22:46:00Z
Pre-hackathon:

We Tux

Day 1

My first day was largely spent analyzing and fixing bugs in the Module::Build::Tiny toolchain, and some Lancaster consensus discussions on various toolchain pieces. This was a very useful day, that ended with some wonderful food.

Day 2

Spent the first part of the day fixing bugs I made the day before, then helped out with other people's issues. Didn't participate in all consensus discussions as PAUSE isn't really my thing. 

Day 3

Only