Ports Search

[ from developer's site ] It is a free library for decoding ATSC A/52 streams, aka AC-3. The A/52 standard is used in a variety of applications, e.g., digital television and DVD. The main goals in liba52 development are: Portability - most of the code is written in C, and when we use platform-specific optimizations we always have a generic C routine to fall back on. Reusability - we do not want liba52 to include any project-specific code, but it should still include enough features to be used by very diverse projects. Precision - We are trying to implement all of the A/52 standard, and to have a very precise output by doing all the calculations in floating point. We have a test suite that detects any deviation in the output when compared to previous versions. We do not have access to official A/52 test vectors though, so we have to use our judgement to ensure that such deviations are only introduced when we fix bugs! Speed - liba52 is really fast, on any modern PC it should take only a few percent of CPU time.

L2A is a simple filter to remove most LaTeX commands from marked-up documents, leaving only the body of text.

mod_whatkilledus is an experimental module for Apache httpd 2.x which tracks the current request and logs a report of the active request when a child process crashes. Requirements: Apache httpd >= 2.0.49 must be built with the --enable-exception-hook configure option and mod_so enabled. Activating mod_whatkilledus: 1. Load it like any other DSO. LoadModule whatkilledus_module modules/mod_whatkilledus.so 2. Enable exception hooks for modules like mod_whatkilledus: EnableExceptionHook On 3. Choose where the report on current activity should be written. If you want it reported to some place other than the error log, use the WhatKilledUsLog directive to specify a fully-qualified filename for the log. Note that the web server user id (e.g., "nobody") must be able to create or append to this log file, as the log file is not opened until a crash occurs.

This perhaps ridiculous-seeming module was created to test routines that manipulate random numbers by providing a known output from rand. Given a list of seeds with srand, it will return each in turn. After seeded random numbers are exhausted, it will always return 0. Seed numbers must be of a form that meets the expected output from rand as called with no arguments -- i.e. they must be between 0 (inclusive) and 1 (exclusive). In order to facilitate generating and testing a nearly-one number, this module exports the function oneish, which returns a number just fractionally less than one. Depending on how this module is called with use, it will export rand to a specified package (e.g. a class being tested) effectively overriding and intercepting calls in that package to the built-in rand. It can also override rand in the current package or even globally. In all of these cases, it also exports srand and oneish to the current package in order to control the output of rand. Alternatively, this module can be used to generate objects, with each object maintaining its own distinct seed array.

K3b is a GUI frontend to the CD recording programs cdrdao and cdrecord. It's aim is to provide a very user friendly interface to all the tasks that come with CD and DVD recording. Features so far: * Creating data CDs (on-the-fly, rockridge, joliet, El-Torito) * Creating audio CDs (WAV, MP3, OGG, CD-TEXT; normalization and on-the fly) * Creating Video CDs (VCD 1.1, 2.0, SVCD, CD-i support (Version 4)) * Creating mixed-mode CDs (CD-Extra (CD-Plus, Enhanced Audio CD)) * Creating eMovix CDs * CD Copy (single + multi session, audio, enhanced audio, cloning) * DVD burning (DVD-R(W), DVD+R(W), eMovix, Formatting DVD-RWs and DVD+RWs) * CD Ripping (CDDB support, CD-TEXT reading, several formats) * DVD Ripping and DivX/XviD encoding * Blanking of CDRWs. * Retrieving Table of contents and cdr information. * Writing existing iso images to CD and DVD. * Writing cue/bin files created for CDRWIN * DVD copy (no video transcoding yet) * Enhanced cd device handling (burnfree and justlink support) * KParts plugin

The DBD::AnyData module provides a DBI/SQL interface to data in many formats and from many sources. Regardless of the format or source of the data, it may be accessed and/or modified using all standard DBI methods and a subset of SQL syntax. In addition to standard database access to files, the module also supports in-memory tables which allow you to create temporary views; to combine data from a number of sources; to quickly prototype database systems; and to display or save the data in any of the supported formats (e.g. to display data in a CSV file as an HTML table). These in-memory tables can be created from any combination of DBI databases or files of any format. They may also be created from perl data structures which means it's possible to quickly prototype a database system without any file access or rdbms backend. The module also supports converting files between any of the supported formats (e.g. save selected data from MySQL or Oracle to an XML file).

The snow package provides support for simple parallel computing on a network of workstations using R. A master R process calls makeCluster to start a cluster of worker processes; the master process then uses functions such as clusterCall and clusterApply to execute R code on the worker processes and collect and return the results on the master. This framework supports many forms of "embarrassingly parallel" computations. Snow can use one of four communications mechanisms: sockets, PVM, MPI, or NetWorkSpaces (NWS). NWS support was provided by Steve Weston. PVM clusters use the rpvm package; MPI clusters use package Rmpi; NWS clusters use package nws. If pvm is used, then pvm must be started, either using a pvm console (e.g the pvm text console or the graphical xpvm console, both available with pvm) or from R using functions provided by rpvm. Similarly, LAM-MPI must be started, e.g. using lamboot, for MPI clusters that use Rmpi and LAM-MPI. If NWS is used, the NetWorkSpaces server must be running. SOCK clusters are the easiest approach for using snow on a single multi-core computer as they require no additional software.

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

ftp.proxy is an application level gateway for FTP. It sits between a client and a server forwarding command and data streams supporting a subset of the file transfer protocol as described in RFC 959. Beside this basic function which makes the program useful on firewall or masqueraders it offers fixing the FTP server (e.g. for connections into a protected LAN) and proxy authentication. -Philippe philippe@le-berre.com