Ports Search

The Log::Agent module provides an abstract layer for logging and tracing, which is independent from the actual method used to physically perform those activities. It acts as an agent (hence the name) that collects the requests and delegates processing to a sublayer: the logging driver. The Log::Agent module is meant to be used in all reusable components, since they cannot know in advance how the application which ends up using them will perform its logging activities: either by emitting messages on stdout and errors on stderr, or by directing messages to log files, or by using syslog(3). The logging interface is common for all the logging drivers, and is therefore the result of a compromise between many logging schemes: any information given at this level must be either handled by all drivers, or may be ignored depending on the application's final choice. WARNING: THIS INTERFACE IS STILL SOMEWHAT ALPHA AND COULD STILL CHANGE DEPENDING ON THE FEEDBACK THE AUTHOR RECEIVES, WITHOUT ANY BACKWARD COMPATIBILITY ASSURANCE.

Pegex is an Acmeist parser framework. It allows you to easily create parsers that will work equivalently in lots of programming languages! The inspiration for Pegex comes from the parsing engine upon which the postmodern programming language Perl 6 is based on. Pegex brings this beauty to the other justmodern languages that have a normal regular expression engine available. Pegex gets it name by combining Parsing Expression Grammars (PEG), with Regular Expessions (Regex). That's actually what Pegex does. PEG is the cool new way to elegantly specify recursive descent grammars. The Perl 6 language is defined in terms of a self modifying PEG language called Perl 6 Rules. Regexes are familiar to programmers of most modern programming languages. Pegex defines a simple PEG syntax, where all the terminals are regexes. This means that Pegex can be quite fast and powerful. Pegex attempts to be the simplest way to define new (or old) Domain Specific Languages (DSLs) that need to be used in several programming languages and environments. Things like JSON, YAML, Markdown etc. It also great for writing parsers/compilers that only need to work in one language.

The ResourcePool is a generic connection caching and pooling management facility. It might be used in an Apache/mod_perl environment to support connection caching like Apache::DBI for non-DBI resources (e.g. Net::LDAP). It's also useful in a stand alone perl application to handle connection pools. The key benefit of ResourcePool is the generic design which makes it easily extensible to new resource types. The ResourcePool has a simple check mechanism to detect and close broken connections (e.g. if the database server was restarted) and opens new connections if possible. If you are new to ResourcePool you should go to the ResourcePool::BigPicture documentation which provides the best entry point to this module. The ResourcePool itself handles always exactly equivalent connections (e.g. connections to the same server with the same user-name and password) and is therefore not able to do a load balancing. The ResourcePool::LoadBalancer is able to do a advanced load balancing across different servers and increases the overall availability by applying a failover policy if there is a server breakdown.

PEAR::PEAR_PackageFileManager revolutionizes the maintenance of PEAR packages. With a few parameters, the entire package.xml is automatically updated with a listing of all files in a package. Features include - can detect PHP and extension dependencies using PHP_CompatInfo - reads in an existing package.xml file, and only changes the release/changelog - a plugin system for retrieving files in a directory. Currently two plugins exist, one for standard recursive directory content listing, and one that reads the CVS/Entries files and generates a file listing based on the contents of a checked out CVS repository - incredibly flexible options for assigning install roles to files/directories - ability to ignore any file based on a * ? wildcard-enabled string(s) - ability to include only files that match a * ? wildcard-enabled string(s) - ability to manage dependencies - can output the package.xml in any directory, and read in the package.xml file from any directory. - can specify a different name for the package.xml file PEAR_PackageFileManager is fully unit tested.

This package revolutionizes the maintenance of PEAR packages. With a few parameters, the entire package.xml is automatically updated with a listing of all files in a package. Features include - manages the new package.xml 2.0 format in PEAR 1.4.0 - can detect PHP and extension dependencies using PHP_CompatInfo - reads in an existing package.xml file, and only changes the release/changelog - a plugin system for retrieving files in a directory. Currently four plugins exist, one for standard recursive directory content listing, one that reads the CVS/Entries files and generates a file listing based on the contents of a checked out CVS repository, one that reads Subversion entries files, and one that queries a Perforce repository. - incredibly flexible options for assigning install roles to files/directories - ability to ignore any file based on a * ? wildcard-enabled string(s) - ability to include only files that match a * ? wildcard-enabled string(s) - ability to manage dependencies - can output the package.xml in any directory, and read in the package.xml file from any directory. - can specify a different name for the package.xml file

ptmalloc is the original version of the malloc that was later included in GNU libc. This version is also but *not* exclusively LGPL: Copyright (c) 2001-2006 Wolfram Gloger Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that (i) the above copyright notices and this permission notice appear in all copies of the software and related documentation, and (ii) the name of Wolfram Gloger may not be used in any advertising or publicity relating to the software. THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL WOLFRAM GLOGER BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. This package comes with no documentation beyond a README, which isn't worth installing. It appears that the GNU libc man page malloc(3) applies, but it's not included here for copyright reasons.

mercurial-server gives your developers remote read/write access to centralized Mercurial repositories using SSH public key authentication; it provides convenient and fine-grained key management and access control. All of the repositories controlled by mercurial-server are owned by a single user (the "hg" user in what follows), but many remote users can act on them, and different users can have different permissions. We don't use file permissions to achieve that - instead, developers log in as the "hg" user when they connect to the repository host using SSH, using SSH URLs of the form "ssh://hg@repository-host/repository-name". A restricted shell prevents them from using this access for unauthorized purposes. Developers are authenticated only using SSH keys; no other form of authentication is supported. To give a user access to the repository, place their key in an appropriately-named subdirectory of "/usr/lcoal/etc/mercurialserver/keys" and run "refresh-auth". You can then control what access they have to what repositories by editing the control file "/usr/local/etc/mercurialserver/access.conf", which can match the names of these keys against a glob pattern. For convenient remote control of access, you can instead (if you have the privileges) make changes to a special repository called "hgadmin", which contains its own "access.conf" file and "keys" directory. Changes pushed to this repository take effect immediately. The two "access.conf" files are concatenated, and the keys directories merged.

dnsjava is an implementation of DNS in Java. It supports all defined record types (including the DNSSEC types), and unknown types. It can be used for queries, zone transfers, and dynamic updates. It includes a cache which can be used by clients, and a minimal implementation of a server. It supports TSIG authenticated messages, partial DNSSEC verification, and EDNS0. dnsjava provides functionality above and beyond that of the InetAddress class. Since it is written in pure Java, dnsjava is fully threadable, and in many cases is faster than using InetAddress. dnsjava provides both high and low level access to DNS. The high level functions perform queries for records of a given name, type, and class, and return an array of records. There is also a clone of InetAddress, which is even simpler. A cache is used to reduce the number of DNS queries sent. The low level functions allow direct manipulation of DNS messages and records, as well as allowing additional resolver properties to be set.

pdnsd is a proxy dns server with permanent caching (the cache contents are written to hard disk on exit) that is designed to cope with unreachable or down dns servers (for example in dial-in networking). pdnsd can be used with applications that do dns lookups, eg on startup, and can't be configured to change that behavior, to prevent the often minute-long hangs (or even crashes) that result from stalled dns queries. Some Netscape Navigator versions for Unix, for example, expose this behavior. pdnsd is configurable via a file and supports run-time configuration using the program pdnsd-ctl that comes with pdnsd. This allows you to set the status flags of servers that pdnsd knows (to influence which servers pdnsd will query), and the addition, deletion and invalidation of DNS records in pdnsd's cache. Parallel name server queries are supported. This is a technique that allows querying several servers at the same time so that very slow or unavailable servers will not block the answer for one timeout interval. Since version 1.0.0, pdnsd has full IPv6 support.

Frodo is a freeware C64 emulator for BeOS, Unix, MacOS, AmigaOS, Win32 and RiscOS systems and the world's first C64 emulator not bearing a "64" in its name. :-) (No, it has absolutely nothing to do with frodo.hiof.no, that's a pure coincidence.) Frodo was developed to reproduce the graphics of games and demos better than the existing C64 emulators. Therefore Frodo has relatively high system requirements: It should only be run on systems with at least a PowerPC/Pentium/68060. But on the other hand, Frodo can display raster effects correctly that only result in a flickering mess with other emulators. Frodo comes in three flavours: The "normal" Frodo with a line-based emulation, the improved line-based emulation "Frodo PC", and the single-cycle emulation Frodo SC that is slower but far more compatible. In addition to a precise 6510/VIC emulation, Frodo features a processor-level 1541 emulation that is even able to handle about 95% of all fast loaders. There is also a faster 1541 emulation for four drives in .d64/x64 disk images, .t64/LYNX archives, or directories of the host system.