This is Gwenhywfar, a multi-platform (*BSD, Linux, MS-Win, etc.)
helper library for networking and security applications and libraries.
It is used by several 'finance' ports, and possibly others.
Gwenhywfar includes the following features, among several others:
- OS abstraction functions for directory and Internet address handling
and library loading (src/os/)
- Networking functions which allow managing many connections to be used
economically even in single threaded applications
- High-level functions for parsing files with a simplified "XML-like"
format and accessing them like a hierarchical database (src/parser/)
It is able to process valid XML files, too.
- High-level cryptographic functions on top of OpenSSL functionality
(src/crypt/)
The ivykis library is a thin, portable wrapper around OS-provided
mechanisms such as epoll(4), kqueue(2), poll(2) and select(2). It was
mainly designed for building high-performance network applications,
but can be used in any event-driver application that uses pollable
file descriptors as its event sources.
Programs written to the ivykis API are generally single-threaded (or
use only a small number of threads), and never block on I/O. All
input and output is done in a nonblocking fashion, with I/O readiness
notification delivered via callback functions.
JSAP: the Java-based Simple Argument Parser
JSAP parses your command line and instantiates objects of types you specify
based upon that command line. If you configure JSAP to expect an Integer on the
command line, and the user does not provide a String that can be converted to
an Integer, JSAP will alert your program to the fact that there was a problem
with the command line. If JSAP indicates that your command line was
successfully parsed, you are guaranteed an Integer when you request that
parameter's value from your program. There's a pretty big (and growing) list of
return types supported by JSAP.
This module will create sorting networks, a sequence of comparisons
that do not depend upon the results of prior comparisons.
There are several algorithms to generate sorting networks. This
module has three of them: Bose and Nelson's, Hibbard's, and
Batcher's Merge Exchange. It also has networks that were found
to be superior in comparison count to those generated automatically
by these algorithms.
There is a flexible formatting function that will allow you to
print out your network in many ways (see documentation). There
is also a graphical output function that will return the network
in an encapsulated postscript, SVG, or text form.
Class::Accessor is a great way to automate the tedious task of
generating accessors and mutators. One small drawback is that due to
the details of the implementation, you only get one __ANON__ entry in
profiling output. That entry contains all your accessors, which can be
a real pain if you're attempting to figure out which of your accessors
is being called six billion times. This module is a development aid
which uses Hook::LexWrap and Sub::Name to talk your accessors into
identifying themselves. While it shouldn't add much additional runtime
overhead (as it acts only Class::Accessor's generator functions), it
has not been designed for production deployment.
This module adds XPath-style matching to your object trees. This means
that you can find nodes using an XPath-esque query with "match()" from
anywhere in the tree. Also, the "xpath()" method returns a unique path
to a given node which can be used as an identifier.
NOTE: This module is not yet a complete XPath implementation. Over
time I expect the subset of XPath supported to grow. See the SYNTAX
documentation in the module POD for details on the current level of
support.
ExtUtils::InstallPaths tries to make install path resolution as easy as
possible.
When you want to install a module, it needs to figure out where to install
things. The nutshell version of how this works is that default installation
locations are determined from ExtUtils::Config, and they may be individually
overridden by using the install_path attribute. An install_base attribute lets
you specify an alternative installation root like /home/foo and prefix does
something similar in a rather different (and more complicated) way. destdir lets
you specify a temporary installation directory like /tmp/install in case you
want to create bundled-up installable packages.
Log::Dump is a simple logger mix-in mainly for debugging. This
installs six methods into a caller (the class that used Log::Dump) via
Sub::Install. The point is you don't need to load extra dumper modules
or you don't need to concatenate messages. Just log things and they
will be dumped (and concatenated if necessary) to stderr, and to a
file if you prefer. Also, you can use these logging methods as class
methods or object methods (though usually you don't want to mix them,
especially when you're doing something special).
Module::Extract is a convenience base class for creating module that work with
Perl distributions. Its purpose is to take care of the mechanisms of locating
and extracting a Perl distribution so that your module can do something specific
to the distribution.
This module was originally created to provide an abstraction for the extraction
logic for both Module::Inspector and Module::P4P and to allow additional
features to be added in the future without having to modify both of them,
because the general problem of "locate, download, and expand a distribution"
is one that is almost ideal for adding additional features down the line.
Someone asked on Perlmonks if a hash could do fuzzy matches on keys - this
is the result.
If there's no exact match on the key that you pass to the hash, then the
key is treated as a regex and the first matching key is returned. You can
force it to leap straight into the regex checking by passing a qr'ed regex
into the hash like this:
my $val = $h{qr/key/};
exists and delete also do regex matching. In the case of delete all values
matching your regex key will be deleted from the hash.