Ports Search

A heap is a partially sorted structure where it's always easy to extract the smallest element. If the collection of elements is changing dynamically, a heap has less overhead than keeping the collection fully sorted. The order in which equal elements get extracted is unspecified. The main order relations supported by this module are "<" (numeric compare) and "lt" (string compare). The internals of the module do nothing with the elements inserted except inspecting the key. This means that if you for example store a blessed object, that's what you will get back on extract. It's also ok to keep references to the elements around and make changes to them while they are in the heap as long as you don't change the key. Heap::Simple itself is just a loader for the code that will actually implement the functionality mentioned above. You will need to install something like Heap::Simple::XS or Heap::Simple::Perl to be able to actually do anything.

InlineX::C2XS - create an XS file from an Inline C file. The C file that InlineX::C2XS needs to find would contain only the C code. InlineX::C2XS looks for the file in ./src directory - expecting that the filename will be the same as what appears after the final '::' in the module name (with a '.c' extension). ie if the module is called My::Next::Mod it looks for a file ./src/Mod.c, and creates a file named Mod.xs. Also created, is the file 'INLINE.h' - but only if that file is needed. The generated xs file (and INLINE.h) will be written to the cwd unless a third argument (specifying a valid directory) is provided to the c2xs() function. The created XS file, when packaged with the '.pm' file, an appropriate 'Makefile.PL', and 'INLINE.h' (if it's needed), can be used to build the module in the usual way - without any dependence upon the Inline::C module.

This is a second go at a module to simplify installing die() and warn() handlers, and to make such handlers easier to write and control. For most people, this just means that if use Religion; then you'll get noticeably better error reporting from warn() and die(). This is especially useful if you are using eval(). Religion provides four classes, WarnHandler, DieHandler, WarnPreHandler, and DiePreHandler, that when you construct them return closures that can be stored in variables that in turn get invoked by $SIG{__DIE__} and $SIG{__WARN__}. Note that if Religion is in use, you should not modify $SIG{__DIE__} or $SIG{__WARN__}, unless you are careful about invoking chaining to the old handler. Religion also provides a TraceBack function, which is used by a DieHandler after you die() to give a better handle on the current scope of your situation, and provide information about where you were, which might influence where you want to go next, either returning back to where

The apptools project includes a set of packages that Enthought has found useful in creating a number of applications. - apptools.appscripting: Framework for scripting applications. - apptools.help: Provides a plugin for displaying documents and examples. - apptools.io: Provides an abstraction for files and folders in a file system. - apptools.logger: Convenience functions for creating logging handlers - apptools.naming: Manages naming contexts, supporting non-string data types and scoped preferences - apptools.permissions: Supports limiting access to parts of an application unless the user is appropriately authorised (not full-blown security). - apptools.persistence: Supports pickling and restoring the state of an object. - apptools.preferences: Manages application preferences. - apptools.selection: Manages the communication between providers and listener of selected items in an application. - apptools.scripting: A framework for automatic recording of Python scripts. - apptools.sweet_pickle: Handles class-level versioning, to support loading of saved data that exist over several generations of internal class structures. - apptools.template: Supports creating templatizable object hierarchies. - apptools.type_manager: Manages type extensions, including factories to generate adapters, and hooks for methods and functions. - apptools.undo: Supports undoing and scripting application commands.

This library is an implementation of the JSON-LD specification in Python. JSON-LD is designed as a light-weight syntax that can be used to express Linked Data. It is primarily intended to be a way to express Linked Data in JavaScript and other Web-based programming environments. It is also useful when building interoperable Web Services and when storing Linked Data in JSON-based document storage engines. It is practical and designed to be as simple as possible, utilizing the large number of JSON parsers and existing code that is in use today. It is designed to be able to express key-value pairs, RDF data, RDFa data, Microformats data, and Microdata. That is, it supports every major Web-based structured data model in use today. The syntax does not require many applications to change their JSON, but easily add meaning by adding context in a way that is either in-band or out-of-band. The syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth migration path from JSON to JSON with added semantics. Finally, the format is intended to be fast to parse, fast to generate, stream-based and document-based processing compatible, and require a very small memory footprint in order to operate.

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.

Celluloid::IO provides an event-driven IO system for building fast, scalable network applications that integrates directly with the Celluloid actor library, making it easy to combine both threaded and evented concepts. Celluloid::IO is ideal for servers which handle large numbers of mostly-idle connections, such as Websocket servers or chat/messaging systems. Celluloid::IO provides a different class of actor: one that's slightly slower and heavier than standard Celluloid actors, but one which contains a high-performance reactor just like EventMachine or Cool.io. This means Celluloid::IO actors have the power of both Celluloid actors and evented I/O loops. Unlike certain other evented I/O systems which limit you to a single event loop per process, Celluloid::IO lets you make as many actors as you want, system resources permitting. Rather than callbacks, Celluloid::IO exposes a synchronous API built on duck types of Ruby's own IO classes, such as TCPServer and TCPSocket. These classes work identically to their core Ruby counterparts, but in the scope of Celluloid::IO actors provide "evented" performance. Since they're drop-in replacements for the standard classes, there's no need to rewrite every library just to take advantage of Celluloid::IO's event loop and you can freely switch between evented and blocking IO even over the lifetime of a single connection.

gFTP is a free multithreaded FTP and SFTP client for Unix-like systems. It has the following features: Distributed under the terms of the GNU Public License Written in C, has a text interface and a GTK+ 2.x interface Supports the FTP, FTPS (control connection only), HTTP, HTTPS, SSH, and FSP Multithreaded to allow for simultaneous downloads File transfer queues to allow for downloading multiple files Bookmarks menu to allow you to quickly connect to remote sites Supports downloading entire directories and subdirectories Extensive connection manager with FTP and HTTP proxy server support Supports resuming interrupted file transfers Supports caching of remote directory listings Supports connecting to a FTP server via command line parameters Supports associating icons with particular file extensions in the list boxes Sorting capabilities in the file list boxes Can restrict files in the list boxes to a particular file specification Supports viewing and editing of local and remote files Allows for passive and non-passive file transfers Supports FXP file transfers (file transfer between 2 remote servers via FTP) Eliminates buffer overruns from malicious FTP sites

This project aims to reimplement the game engine of Theme Hospital, and be able to load the original game data files. This means that you will need a purchased copy of Theme Hospital, or a copy of the demo, in order to use CorsixTH. After most of the original engine has been reimplemented, the the project will serve as a base from which extensions and improvements to the original game can be made. At the moment, game assets (graphics, sounds, levels, translations, etc.) are loaded from the original game files. Therefore, you will require a pre-existing Theme Hospital install in order to use CorsixTH. If you've got a copy of the original game disk lying around, then great -- copy the HOSP folder (which should contain directories called Data, QData, Levels, etc.) from the root of the CD to somewhere on your hard drive, and use this for the theme_hospital_install setting later. If you are unable to acquire the full game data files, then the demo can be downloaded easily and used instead (though the demo only has one level, and lacks most of the management screens).

Liquid War is a unique multiplayer wargame. Its rules are truely original and have been invented by Thomas Colcombet. You control an army of liquid and have to try and eat your opponents. A single player mode is available, but the game is definitely designed to be multiplayer, and has network support. When playing Liquid War, one has to eat one's opponent. There can be from 2 to 6 players. There are no weapons, the only thing you have to do is to move a cursor in a 2-D battlefield. This cursor is followed by your army, which is composed by a great many little fighters. Fighters are represented by small colored squares. All the fighters who have the same color belong to the same team. One very often controls several thousands fighters at the same time. And when fighters from different teams meet, they eat each other, it is as simple as that. Note: If the game crashes this might resolve it: Inside liquidwar, go to options->rules->advanced and change Algorithm from "Assembly" to "Standard C" See also the "ASM" option in the port build options.