Ports Search

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.