Ports Search

SimpleParse is a BSD-licensed Python package providing a simple and fast parser generator using a modified version of the mxTextTools text-tagging engine. SimpleParse allows you to generate parsers directly from your EBNF grammar. Unlike most parser generators, SimpleParse generates single-pass parsers (there is no distinct tokenization stage), an approach taken from the predecessor project (mcf.pars) which attempted to create "autonomously parsing regex objects". The resulting parsers are not as generalized as those created by, for instance, the Earley algorithm, but they do tend to be useful for the parsing of computer file formats and the like (as distinct from natural language and similar "hard" parsing problems). As of version 2.1.0 the SimpleParse project includes a patched copy of the mxTextTools tagging library with the non-recursive rewrite of the core parsing loop. This means that you will need to build the extension module to use SimpleParse, but the effect is to provide a uniform parsing platform where all of the features of a give SimpleParse version are always available.

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.

From its homepage: xpuyopuyo is a UNIX port of a very big time sink :) . Puyo puyo is a puzzle game, somewhat like Tetris, where you strive to match up four "blobs" of the same color. Each match you make gives points, and also dumps gray rocks on the opponent which are irritating and troublesome to get rid of. Multiple matches at a time score more points, and dump more rocks on the opponent (a quintuple-match will dump around 20 rocks on the opponent, all at once). We ported it overnight to Linux, so we could play whenever we felt like. The AI's evolved more slowly, over the course of a week or so. I welcome sugges- tions on how to make the AI's more difficult during the game; currently, they are rather easy to beat on easy level, but more difficult on hard. There are still gaping holes in the game interface which should be fixed soon. Sugges- tions for improvements are welcome.

DiaCanvas is in its second incarnation: DiaCanvas2. Aiming towards future computing needs on GNOME based desktop environments, DiaCanvas2 is providing you with a full featured diagramming canvas: - Model/View/Controller based design: The DiaCanvas class only holds abstract data (using DiaShape objects), the data is rendered by one or more DiaCanvasView's. - Usage of the widely used GnomeCanvas for visualization. This makes it easy to let DiaCanvas2 display anti-aliased diagrams with translucency (alpha) support. - Export facilities for GnomePrint and SVG. - Objects can be rotated/sheared/resized/etc. without the need to recalculate shapes. DiaCanvas relies heavily on the LibArt library (which is a standard GNOME library). - Objects can connect to each other with handles. The connection is represented as a mathematical equation, which is solved using a real linear constraint solver (see the reference documentation for more info). Handles do not need predefined connection points, but can connect to each other in a more generic way. - Of course DiaCanvas2 has all the features a modern application needs, including undo/redo and copy/paste functionality (copying is not implemented yet).

INTERGIF 6.15 is a program for joining GIFs together (for animation), or splitting animations apart, or for optimising animations created by other programs. * Supports the animation, transparency and interleaving features of GIF89a. * Eliminates unused palette entries. * Minimises the final size of the GIF with a devious and cunning optimisation routine: almost every animated GIF the author has found on the web ends up smaller when run through InterGif. * Can forcibly reduce a GIF's palette to the standard Acorn 256-colour palette, or to a 216-entry "web safe" colour cube (as used on the Macintosh and by most Windows browsers),or to a palette file you supply. Alternatively, it can calculate the best palette for displaying the GIF, and then reduce to that. * From version 6.03, this also works with 16bpp and 24bpp input images -- and with GIFs which use more than 256 colours in total. (GIFs can only use 256 colours per frame, but each frame can have its own palette.) * Lets you trim away any wholly transparent rows or columns from the edges of your GIF (whether single-frame or animated). * Can dither 16bpp or 24bpp input files to whatever palette is required (error diffusion implementation kindly donated by Martin Wurthner).

This is a pure-Java implementation of Berkeley DB by SleepyCat (now Oracle). Java-1.7 is required for building. From the "Berkeley DB JE was designed from the ground up in Java. It takes full advantage of the Java environment. The Berkeley DB JE API provides a Java Collections-style interface, as well as a programmatic interface similar to the Berkeley DB API. Berkeley DB JE is different from all other Java databases available today. Berkeley DB JE is not a relational engine built in Java. It is a Berkeley DB-style embedded store, with an interface designed for programmers, not DBAs. Berkeley DB JE's architecture employs a log-based, no-overwrite storage system, enabling high concurrency and speed while providing ACID transactions and record-level locking. Berkeley DB JE efficiently caches most commonly used data in memory, without exceeding application-specified limits. In this way Berkeley DB JE works with an application to use available JVM resources while providing access to very large data sets. The Berkeley DB JE architecture provides an underlying storage layer for any Java application requiring high performance, transactional integrity and recoverability."

Groovy is an agile dynamic language for the Java 2 Platform that has many of the features that people like so much in languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax. Groovy is designed to help you get things done on the Java 2 Platform in a quick, concise and fun way. Groovy brings the power of a scripting language directly into the Java 2 Platform. For example: - Shell scripting using Groovy allows the full power of the Java Platform to be brought to bear to the task at hand. - Groovy can be used (and indeed is already being used) as a replacement for Java for small and medium sized applications to execute on the Java 2 Platform. - Groovy can be used as an embedded language for dynamic business rules or extension points utilizing the agility of Groovy and saving the cost of redeploying applications for each change of rule (especially when the rules are stored in a database). - Groovy makes writing test cases for unit tests very easy. As well as being a powerful language for scripting Java objects, Groovy can be used as an alternative compiler to javac to generate standard Java bytecode to be used by any Java project.

Scheme 48 is an implementation of the Scheme programming language as described in the Revised^5 Report on the Algorithmic Language Scheme. It is based on a compiler and interpreter for a virtual Scheme machine. The name derives from our desire to have an implementation that is simple and lucid enough that it looks as if it were written in just 48 hours. We don't claim to have reached that stage yet; much more simplification is necessary. Scheme 48 is an implementation of the Scheme programming language as described in the Revised5 Report on the Algorithmic Language Scheme [6]. It is based on a compiler and interpreter for a virtual Scheme machine. Scheme 48 tries to be faithful to the Revised5 Scheme Report, providing neither more nor less in the initial user environment. (This is not to say that more isn't available in other environments; see below.) Scheme 48 is under continual development. Please report bugs, especially in the VM, especially core dumps, to scheme-48-bugs@s48.org. Include the version number x.yy from the "Welcome to Scheme 48 x.yy" greeting message in your bug report. It is a goal of this project to produce a bullet-proof system; we want no bugs and, especially, no crashes.

The skem utility is a sendmail milter, that checks and maintains a list of whitelisted, temporary banned, and permanently blacklisted IP-addresses. How you obtain the entries is up to you, but the included logwatcher module provides one possibility. The list is stored in a directory, each entry being a file (usually -- zero sized) or a symlink (usually -- a "broken" one). Such entries are stored efficiently (within the directory itself) and the directories are searched using the hash tables on modern file systems. At the same time, they can be listed, added, and removed with the simple ls(1), touch(1), and rm(1). This milter does not itself filter spam, instead it memorizes the verdicts issued by your other anti-spam defenses to reduce the system load and resource consumption, by temporarily rejecting the relays suspected of spamming (banned) and, optionally, by permanently rejecting the relays "convicted" of spamming (blacklisted). The idea is to stem the spam from real spam sources, while reducing the ill effects of false-positives to merely delaying, rather than rejecting future messages.

KKTDirect implements an ordering method and accompanying factorization for the direct solution of saddle-point matrices (also known as KKT or equilibrium matrices). A simple constraint on ordering together with an assumption on the rank of parts of the matrix are sufficient to guarantee the existence of the LDL^T factorization, stability concerns aside. In fact, D may be taken to be a diagonal matrix with +/-1 along the diagonal, and be fully determined prior to factorization, giving rise to a "signed Cholesky" factorization. A modified minimum-degree-like algorithm which incorporates this constraint is used, along with a simple algorithm to modify an existing fill-reducing ordering to respect the constraint. While a stability analysis is lacking, numerical experiments indicate that this is generally sufficient to avoid the need for numerical pivoting during factorization, with clear possible benefits for performance. Note this is only alpha-quality proof-of-concept code: for example, out-of-memory errors are not handled gracefully, and the provided Minimum Degree routine is not yet competitive with other packages.