Ports Search

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.