List::GroupBy provides functions to group a list of hashrefs in to a hash of hashrefs of arrayrefs.

FUNCTIONS

• groupBy( [ 'primary key', 'secondary key', ... ], LIST )

  If called with and array ref as the first parameter then groupBy will group the list by the keys provided in the array ref.

  Note: undefined values for a key will be defaulted to the empty string.

  Returns a hash of hashrefs of arrayrefs

• groupBy( { keys => [ 'key', ... ], defaults => { 'key' => 'default', ... }, operations => { 'key' => sub, ... }, LIST )

  More advanced options are available by calling groupBy with a hash ref of options as the first parameter. Available options are:

  • keys (Required)

    An array ref of the keys to use for grouping. The order of the keys dictates the order of the grouping. So the first key is the primary grouping, the second key is used for the secondary grouping under the primary grouping an so on.

  • defaults (Optional)

    A hash ref of defaults to use one or more keys. If a key for an item is undefined and there's an entry in the defaults option then that will be used. If no default value has been supplied for a key then the empty string will be used.

  • operations (Optional)

    A hash ref mapping keys to a function to use to normalise value's when grouping. If there's no entry for a key then the value is just used as is.

    Each funtion is passed the value as it's only parameter and it's return value is used for the key.

  Returns a hash of hashrefs of arrayrefs

Pretty self explanatory

A set of tools for testing paths.

Should also include:

• file_exists
• file_readable
• file_writable

same with dir:

• dir_exists
• dir_writable (has w)
• dir_accesible (has r and x) #?

And all of the above with '!'

This is a Test2 plugin that provides annotations for failed tests running in GitHub Actions workflow, using a workflow command. You can use it with use Test2::Plugin::GitHub::Actions::AnnotateFailedTest regardless of running in GitHub Actions workflow or not.

Questions

• Is the name appropriate?
• Can I publish it to CPAN from current master branch and install successfully? (Are the dependencies enough?)

This is a module for parsing /sys/class/input/input*/capabilities/* which is a Linux-specific interface. Linux exports all the events that the device can report, separated into several categories (some stretching belief in calling them input devices, like the PC speaker — but that's what Linux does). Linux unfortunately exports these as bit strings, encoded in hex, split in to words without leading zeros. And yes, word length does vary by architecture.

The modules already include POD. And some tests, too.

The …::Constants module is auto-generated from the Linux C headers by InputCapsFromHeader.pm. Which isn't a NIH re-implementation of h2xs, I'm pretty sure.

Modules in the neighborhood I'm aware of:

• Linux::Input, which I believe is mainly for getting the events from the devices and looks like it requires permission to actually open the devices. (I don't think I'm stepping on its namespace, as there are already multiple modules under Linux::Input:: by different authors).
• Linux::Input::Info — reads the easy files, does not do capabilities. Possibly my module could be merged into this, but last update of 2008 doesn't give me much hope. Also, this appears to be opening the device in /dev, not using /sys.

The synopsis, tested on a VM, spits out:

Input devices found (numbers): 0, 4, 2, 3, 5
Input device found: input0, AT Translated Set 2 keyboard
Input device found: input4, Power Button
Input device found: input2, ImExPS/2 Generic Explorer Mouse
Input device found: input3, QEMU QEMU USB Tablet
Input device found: input5, PC Speaker
Device AT Translated Set 2 keyboard answers questions

BTW: This is currently part of an application I'm writing, App::ABAN, and currently it lives in the same repository. I'm thinking I'll move it to its own, or at least build it separately, once its ready for CPAN. (My PAUSE ID hasn't be processed yet, so I've been working on other things).

The linked gist is the initial draft of a module that allows Rex to show diffs on the terminal upon file changes during task execution. I'm posting it here both for early availability and early feedback.

I think it is a good example of how to extend Rex without changing the core, and publishing on CPAN would be a great way to share.

Additional features could include colored output support, and pluggable diff backends (like Text::Diff::Unified::XS, or even using diff binary, if present).

The name is following this logic: it extends Rex via a Hook for File operations to show the Diff of changes. It could be more specific (e.g. Rex::Hook::File::Diff::Unified), but I feel it's already getting long, so I tried to find a good balance.

Some questions I am wondering about:

• is there a better fit for the name?
• would it be possible/easy to merge this into Rex core distribution later (which already has Rex::Hook)?
• is there a better approach to generate diffs?

Feedback welcome both here and on the gist.

Motivation

I'm currently playing with async-await in Mojolicious. It's great.

When I want to call a lot of external commands, I noticed that there is no way to limit concurrent calls to external commands. So I tried creating Mojo::Promise::Limitter.

Questions

• Is there already a module that has the same functionality as this module?
• Any feedback (including implementation) is welcome.

This simple module should enumerate all domain controllers via DNS SRV records.

I have a problem to find a proper name - Net::DNS::ActiveDirectory::DomainController::Discovery is way too long.

Any better ideas?

Small, 2-file module providing practical, useful Perl regex functionality. Pattern matching, obtain 'to' and 'from' match indices, substitute part of a pattern match, and substitute all matching patterns with a new pattern.

Just running this by everyone and wondering what is thought...

It's a small, 2-file collection OO wrapper providing Perl Regex functionality. Matching, substitution, to/from matching index info, etc. are available.

Regex::Wrapper and Regex::Wrapper::Match are the package names.

The code in the 'Synopsis' section closest to the bottom is some 'driver' code that exercises the packages.

Thanks to anyone who takes the time to check this out.

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.