This dist would consist of two modules

MooX::TwoWayRelations - adds the has_two_way function to set up an two-way attribute.

Moo::BrightChild::Role - a child that knows who it's parents is/are.

I'm clueless on implementation details. Thought I'd throw the idea out there (and also hear if it exists). I would not know what names to search for.

The module provides the function 'one' which assures there is only one element returned in list context from the preceding expression.

I repeat this pattern again and again, checking if the outcome provides only the one thing I search for, where finding none or two or more will be an error, repeating the same checks and the same error messagse over and over. 'one' solves that.

The idea is to avoid this pattern:

my @errors;

push @errors, "foo" if bar();

push @errors, "bar" if baz();

die join "\n", @errors if @errors;

It's not a dramatic reduction in code lines, but it is a nice reduction in programmer brain usage on mundane everyday boring things.

Wrappers around copy() and move() in File::Copy that check if destionation exists, and if so changes the destination name to something available.

This dist will provide a script that sets up automatic version string generation for source code, using a template. $AUTOVERSION$ is proposed.

Whenever $AUTOVERSION$ is encountered, it gets substituted with git describe --tags minus the trailing shasum, eg v0.9.1.0. A safe fallback is set up incase no tags exist.

An added bonus is that every commit following a tag, will append a running number to the versionstring, ie next commit it will be v0.9.1.0-1, then -2, etc. until next tag.

The dist would also provide scripts to do the actual filtering, to be used by the filers.

A role that accepts a single filename or a normal hash[ref] to constructor with a file argument

It requires and runs $self->parse after construction.

It provides a fh method that gives a file handle seek'ed to 0 (when it's seekable), which is nice to have in sub parse.

And:

• if given a local file resource: checks that the file exists and is readable
• also accepts a file handle
• also accepts a scalar ref to some content to be parsed
• accepts url's

In short - all those boring tedious things that you have to re-do every time you want to parse a file.

With this shiny role you can skip all that and get straight to the fun bit: The parsing.

The synapsis is pretty self-explanatory, using POE::XS::Loop::EPoll, or similar, provide state changes and pin control on GPIO pins to POE.

Essentially integrate GPIO pin operations as easily as possible into your project, simple as that. In an ideal world.

Lexically scope elevated code, as the example shows. This will most likely mean invoking the system's sudo in one way or another. Typically a password prompt. With a fatal error if it fails.

I don't see 100% how to pull this off, localizing $> most likely, and invoking system's sudo to do so.

EDIT: Changed it from a label (SUDO:) to a sub SUDO (&)

Usage is near identical to POE::Component::Client::HTTP only WWW::Mechanize is used internally to massage the request before submit, and is fed the response back to keep track of cookies etc. as if W::M had sent the request itself.

Uses WWW::Mechanized and PoCo::Client::HTTP internally.

A more sophisticated lazy construction, the sample code pretty much says it all. The module name is perhaps not 100% presize, it does not reflect that the lazy args come from constructor.