Ports Search

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.

The Py-Interface is a python-implementation of an Erlang node. The py_interface provides the possibility to create a node that may be used for communication with other Erlang nodes. Some characteristics: o The Python nodes are hidden, like the Java nodes o The Python node supports - registering the Python node in the epmd - sending and receiving message - executing remote procedure calls (the rpc:call(M,F,A) mechanism) o The Python node does currently not do: - linking - tracing o The Python node translates Erlang types to Python types as far as there is a reasonable Python counterpart. If there is not, then a class is used. o The Python node is a single threaded callback-driven process. o The Python node runs on Python 2.5 and Erlang R12. It may well still work with older version of both Python and Erlang. Development started on Python 1.5 and Erlang R7.

`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.

Blocks - a small tty based games using ncurses =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Written by marc welz (rather : kluged by marc welz) - Redistribution is subject to the GNU public license. Notes ----- Good idea to restrict file names to 20 chars. The editor tries to fill the entire screen - so if you write a level on a big screen, you will not be able to play it on a small one. And remember to save the game you are editing before exiting. Probably contains bugs - but if I knew what they were they would not be there ... Thanks ------ A big THANK YOU goes to Joey Hess (jeh22@conell.edu) who contributed the pyramid level, wrote the man pages for the game and pointed out a couple of minor bugs.