Ports Search

Cdparanoia is a Compact Disc Digital Audio (CDDA) Digital Audio Extraction (DAE) tool, commonly known on the net as a 'ripper'. The application is built on top of the Paranoia library, which is doing the real work (the Paranoia source is included in the cdparanoia source distribution). Cdparanoia reads audio from the CDROM directly as data, with no analog step between, and writes the data to a file or pipe in WAV, AIFC, or raw 16 bit linear PCM. Cdparanoia is a bit different than most other CDDA extraction tools. It contains few-to-no 'extra' features, concentrating only on the ripping process and knowing as much as possible about the hardware performing it. Cdparanoia will read correct, rock-solid audio data from inexpensive drives prone to misalignment, frame jitter, and loss of streaming during atomic reads. Cdparanoia will also read and repair data from CDs that have been damaged in some way. Cdparanoia is easy to use and administrate. It has no compile time configuration, happily autodetecting the CDROM, its type, its interface and other aspects of the ripping process at runtime. A single binary can serve the diverse hardware of the do-it-yourself computer laboratory from Hell.

This program allows you to record the output of any standard OSS program (one that uses /dev/dsp for sound) without having to modify or recompile the program. It uses the same idea as the esddsp wrapper from the Enlightened Sound Daemon (in fact, vsound is based on esddsp). That is, it preloads a library that intercepts calls to open /dev/dsp, and instead returns a handle to a normal file. It also intercepts ioctl's on that file handle and logs them, to help convert the audio data from its raw form. Vsound then uses sox to convert the raw data to the desired file format. The upshoot of this is that instead of playing sound to the sound card in your computer, the data is recorded to a file. This is similar to if you connected a loopback cable to the line in and line out jacks on your sound card, but no DA or AD conversions take place, so quality is not lost.

PhyML is a software that estimates maximum likelihood phylogenies from alignments of nucleotide or amino acid sequences. It provides a wide range of options that were designed to facilitate standard phylogenetic analyses. The main strengths of PhyML lies in the large number of substitution models coupled to various options to search the space of phylogenetic tree topologies, going from very fast and efficient methods to slower but generally more accurate approaches. It also implements two methods to evaluate branch supports in a sound statistical framework (the non-parametric bootstrap and the approximate likelihood ratio test). PhyML was designed to process moderate to large data sets. In theory, alignments with up to 4,000 sequences 2,000,000 character-long can analyzed. In practice however, the amount of memory required to process a data set is proportional of the product of the number of sequences by their length. Hence, a large number of sequences can only be processed provided that they are short. Also, PhyML can handle long sequences provided that they are not numerous. With most standard personal computers, the "comfort zone" for PhyML generally lies around 3 to 500 sequences less than 2,000 character long.

CIDER is a mixed-level circuit and device simulator. CIDER attempts to provide greater simulation accuracy than a stand-alone circuit or device simulator can provide. CIDER is based on the sequential mixed-level circuit and device simulator, CODECS. In common with CODECS, CIDER embeds the circuit simulator, SPICE3, which provides circuit simulation capabilities, analytical models for semiconductor devices, and an interactive user interface. An interface to the captive device simulator, DSIM, provides accurate, one- and two-dimensional numerical models based on the solution of Poisson's equation, and the electron and hole current- continuity equations. The input format of CIDER couples SPICE-like circuit descriptions to a device description format similar to the one used by the PISCES device simulator developed at Stanford University. As a result, CIDER should seem reasonably familiar to designers already accustomed to both these tools. SPICE is a general-purpose circuit simulation program for nonlinear DC, nonlinear transient, and linear AC analyses. Circuits may contain resistors, capacitors, inductors, mutual inductors, independent voltage and current sources, four types of dependent sources, lossless and lossy transmission lines (two separate implementations), switches, uniform distributed RC lines, and the five most common semiconductor devices: diodes, BJTs, JFETs, MESFETs, and MOSFETs.

GnuCap is the GNU Circuit Analysis Package. The primary component is a general purpose circuit simulator. It performs nonlinear dc and transient analyses, fourier analysis, and ac analysis. It is fully interactive and command driven. It can also be run in batch mode or as a server. Spice compatible models for the MOSFET (level 1-7) and diode are included in this release. GnuCap is not based on Spice, but some of the models have been derived from the Berkeley models. Unlike Spice, the engine is designed to do true mixed-mode simulation. Most of the code is in place for future support of event driven analog simulation, and true multi-rate simulation. If you are tired of Spice and want a second opinion, you want to play with the circuit and want a simulator that is interactive, you want to study the source code and want something easier to follow than Spice, or you are a researcher working on modeling and want automated model generation tools to make your job easier, try GnuCap.

Lots of times, Class::DBI is used in web-based applications. (In fact, coupled with a templating system that allows you to pass objects, such as Template::Toolkit, Class::DBI is very much your friend for these.) And, as we all know, one of the most irritating things about writing web-based applications is the monotony of writing much of the same stuff over and over again. And, where there's monotony there's a tendency to skip over stuff that we all know is really important, but is a pain to write - like Taint Checking and sensible input validation. (Especially as we can still show a 'working' application without it!). So, we now have CGI::Untaint to take care of a lot of that for us. It so happens that CGI::Untaint also plays well with Class::DBI. All you need to do is to 'use Class::DBI::FromCGI' in your class (or in your local Class::DBI subclass that all your other classes inherit from. You do do that, don't you?).

This is an SQL to OO mapper with an object API inspired by Class::DBI (with a compatibility layer as a springboard for porting) and a resultset API that allows abstract encapsulation of database operations. It aims to make representing queries in your code as perl-ish as possible while still providing access to as many of the capabilities of the database as possible, including retrieving related records from multiple tables in a single query, JOIN, LEFT JOIN, COUNT, DISTINCT, GROUP BY, ORDER BY and HAVING support. DBIx::Class can handle multi-column primary and foreign keys, complex queries and database-level paging, and does its best to only query the database in order to return something you've directly asked for. If a resultset is used as an iterator it only fetches rows off the statement handle as requested in order to minimise memory usage. It has auto-increment support for SQLite, MySQL, PostgreSQL, Oracle, SQL Server and DB2 and is known to be used in production on at least the first four, and is fork- and thread-safe out of the box (although your DBD may not be). This project is still under rapid development, so large new features may be marked EXPERIMENTAL - such APIs are still usable but may have edge bugs. Failing test cases are *always* welcome and point releases are put out rapidly as bugs are found and fixed.

pgloader imports data from a flat file and inserts it into one or more PostgreSQL database tables. It uses a flat file per database table, and you can configure as many Sections as you want, each one associating a table name and a data file. Data are parsed and rewritten, then given to PostgreSQL COPY command. Parsing is necessary for dealing with end of lines and eventual trailing separator characters, and for column reordering: your flat data file may not have the same column order as the database table has. pgloader is also able to load some large objects data into PostgreSQL, as of now only Informix UNLOAD data files are supported. This command gives large objects data location information into the main data file. pgloader parse it add the text or bytea content properly escaped to the COPY data. pgloader issues some timing statistics every "commit_every" commits. At the end of processing each section, a summary of overall operations, numbers of rows copied and commits, time it took in seconds, errors logged and database errors is issued.

The primary goal of this project is to define a portable and efficient C programming interface (API) to determine the call-chain of a program. The API additionally provides the means to manipulate the preserved (callee-saved) state of each call-frame and to resume execution at any point in the call-chain (non-local goto). The API supports both local (same-process) and remote (across-process) operation. As such, the API is useful in a number of applications. Some examples include: o exception handling The libunwind API makes it trivial to implement the stack-manipulation aspects of exception handling. o debuggers The libunwind API makes it trivial for debuggers to generate the call-chain (backtrace) of the threads in a running program. o introspection It is often useful for a running thread to determine its call-chain. For example, this is useful to display error messages (to show how the error came about) and for performance monitoring/analysis. o efficient setjmp() With libunwind, it is possible to implement an extremely efficient version of setjmp(). Effectively, the only context that needs to be saved consists of the stack-pointer(s).

The rather wacky idea behind this module and its sister module DBD::AnyData is that any data, regardless of source or format should be accessible and modifiable with the same simple set of methods. This module provides a multi- dimensional tied hash interface to data in a dozen different formats. The DBD::AnyData module adds a DBI/SQL interface for those same formats. Both modules provide built-in protections including appropriate flocking() for all I/O and (in most cases) record-at-a-time access to files rather than slurping of entire files. Currently supported formats include general format flat files (CSV, Fixed Length, etc.), specific formats (passwd files, httpd logs, etc.), and a variety of other kinds of formats (XML, Mp3, HTML tables). The number of supported formats will continue to grow rapidly since there is an open API making it easy for any author to create additional format parsers which can be plugged in to AnyData itself and thereby be accessible by either the tiedhash or DBI/SQL interface.