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.