This is a sister module of Parse::PMFile. This module parses local
.pm files (and a META file if any) in a specific (current if not
specified) directory, and returns a hash reference that represents
"provides" information (with some extra meta data). This is almost
the same as Module::Metadata does (which has been in Perl core since
Perl 5.13.9). The main difference is the most of the code of this
module is directly taken from the PAUSE code as of June 2013. If you
need better compatibility to PAUSE, try this. If you need better
performance, safety, or portability in general, Module::Metadata may
be a better and handier option (Parse::PMFile (and thus
Parse::LocalDistribution) actually evaluates code in the $VERSION line
(in a Safe compartment), which may be problematic in some cases).
This module is a first crack at providing a consistent interface to
Unix (and maybe other multitasking OS's) process table information.
The impetus for this came about with my frustration at having to parse
the output of various systems' ps commands to check whether specific
processes were running on different boxes at a large mixed Unix site.
The output format of ps was different on each OS, and sometimes
changed with each new release of an OS. Also, running a ps subprocess
from within a perl or shell script and parsing the output was not a
very efficient or aesthetic way to do things.
With this module, you can do things like this:
# kill memory pigs
use Proc::ProcessTable;
$t = new Proc::ProcessTable;
foreach $p ( @{$t->table} ){
if( $p->pctmem > 95 ){
$p->kill(9);
}
}
Releasing a new version of software takes a lot of steps... finding
the next version number (and making sure you didn't already use that
version number before), making sure your changelog is updated, making
sure your "make dist" results in a tarball that builds, committing
changes (with updated version number), tagging, and uploading the
tarball somewhere.
Or maybe more steps. Or not some of the above. Maybe you forgot
something! And maybe you manage multiple projects, and each project
has a different release process.
This is all a pain in the ass.
You want to be hacking, not jumping through hoops.
Your contributors want to see their patches actually make it into a
release, which won't happen if you're afraid of releases.
shipit automates all the hell. It makes life beautiful.
Test::WWW::Mechanize is a subclass of WWW::Mechanize that incorporates
features for web application testing. The Test::WWW::Mechanize::Catalyst
module meshes the two to allow easy testing of Catalyst applications
without needing to starting up a web server.
Testing web applications has always been a bit tricky, normally
requiring starting a web server for your application and making real
HTTP requests to it. This module allows you to test Catalyst web
applications but does not require a server or issue HTTP requests.
Instead, it passes the HTTP request object directly to Catalyst. Thus
you do not need to use a real hostname: "http://localhost/" will do.
However, this is optional. The following two lines of code do exactly
the same thing:
Starting with Perl 5.10, it is possible to create a lexical version of the Perl
default variable $_. Certain Perl constructs like the given keyword
automatically use a lexical $_ rather than the global $_.
It is occasionallly useful for a sub to be able to access its caller's $_
variable regardless of whether it was lexical or not. The (_) sub prototype is
the official way to do so, however there are sometimes disadvantages to this; in
particular it can only appear as the final required argument in a prototype, and
there is no way of the sub differentiating between an explicitly passed argument
and $_.
The lexical::underscore function returns a scalar reference to either a lexical
$_ variable somewhere up the call stack (using PadWalker magic), or to the
global $_ if there was no lexical version.
Wrapping lexical::underscore in ${ ... } dereferences the scalar reference,
allowing you to access (and even assign to) it.
`slibtool` is an independent reimplementation of the widely used libtool,
written in C. `slibtool` is designed to be a clean, fast, easy-to-use
libtool drop-in replacement, and is accordingly aimed at package authors,
distro developers, and system integrators. `slibtool` maintains compatibility
with libtool in nearly every aspect of the tool's functionality as well as
semantics, leaving out (or turning into a no-op) only a small number of
features that are no longer needed on modern systems.
Being a compiled binary, and although not primarily written for the sake of
performance, building a package with `slibtool` is often faster than with its
script-based counterpart. The resulting performance gain would normally vary
between packages, and is most noticeable in builds that invoke libtool a large
number of times, and which are characterized by the short compilation duration
of individual translation units.
YADIFA is a lightweight authoritative Name Server with DNSSEC capabilities.
Developed by the passionate people behind the .eu top-level domain, YADIFA has
been built from scratch to face today?s DNS challenges, with no compromise on
security, speed and stability, to offer a better and safer Internet experience.
YADIFA has a simple configuration syntax and can handle more queries per second
while maintaining one of the lowest memory footprints in the industry. YADIFA
also has one of the fastest zone file load times ever recorded on a name
server.
YADIFA was developed on FreeBSD and a GNU/Linux. It works on OSX and will be
soon ported to other Unix flavours like OpenBSD and Solaris. A Microsoft
Windows version is also on the cards.
Mednafen is a portable, utilizing OpenGL and SDL, argument(command-line)-driven
multi-system emulator with many advanced features. The Atari Lynx, GameBoy,
GameBoy Color, GameBoy Advance, NES, PC Engine(TurboGrafx 16), and SuperGrafx
are emulated. Mednafen has the ability to remap hotkey functions and virtual
system inputs to a keyboard, a joystick, or both simultaneously. Save states
are supported, as is real-time game rewinding. Screen snapshots may be taken at
the press of a button, and are saved in the popular PNG file format.
Mednafen is distributed under the terms of the GNU GPL.
Due to the threaded model of emulation used in Mednafen, and limitations of SDL
a joystick is preferred over a keyboard to play games, as the joystick will have
slightly less latency, although the latency differences may not be perceptible
to most people.
[This is David Hedley's original README, FreeBSD port comments below]
PC Emulator for Unix and X Windows
As the title suggests, this is a Unix/X windows program which is
designed to emulate a standard 8086 based PC.
The emulator runs at about 8-10MHz 80286 speed on a Sun SparcStation
10/40 (without the -mviking flag) and at about 6MHz 8088 speed on a
33MHz 80486 box running Linux.
I have included a Postscript representation of my project report. It's
a bit out of date now, but it's the closest thing I've got to
documentation! I'll do some kind of latex thing for the next
release....
The program rather hogs the cpu but unmapping the window (iconifying
it) will put it to sleep.
The author is:
David Hedley, hedley@cs.bris.ac.uk
"A Tron clone in 3D"
This has been the tagline of Armagetron, since, well, a very long time, and is
probably the shortest and most accurate description possible. Tron was an
arcade game based on the movie of the same name, release by Disney in 1982. The
original game consisted of 4 sub-games, the only one of concern is the 'Light
Cycles' one, in which the player uses a left/right joystick to control a 'Light
Cycle' which leaves a wall behind it wherever the cycle it goes, turning only
at 90 degree angles (well, on most servers anyways). The player must then force
his opponents to crash into their wall while avoiding his opponents walls.
Those were the humble beginnings of Armagetron Advanced's game play, which has
now blossomed into 16 player mayhem, with highly advanced AI, network game
play, and of course all in a 3D environment.