List::GroupBy Group a list of hashref's to a multilevel hash of hashrefs of arrayrefs
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
Test2::Tools::Path Test tools for checking paths
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 '!'
Test2::Plugin::GitHub::Actions::AnnotateFailedTest Annotate failed tests with GitHub Actions workflow command
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?)
Linux::Input::Capabilities Read /sys to determine the event types attached input devices can emit
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 underLinux::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).
Rex::Hook::File::Diff Show diff of file changes during a Rex run
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.
Mojo::Promise::Limitter limit outstanding calls to Mojo::Promise
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.
Net::DNS::DomainController::Discovery Discover Microsoft Active Directory domain controllers via DNS
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?
Regex::Wrapper OO Perl Regex Wrapper
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.
Regex::Wrapper OO Perl Regex Wrapper
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.
MooX::TwoWayAttribute Allow attributes to know who owns them
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.