• an accurate version number within the shared library, allowing applications to select the appropriate data structures and functions to use at runtime, and
• a simplified interface with an unchanging ABI to the most common decoding functionality within FFmpeg.
• AVbin is distributed as a single dynamic library (.so on GNU/Linux, .dylib on Mac OS X, and .dll on Windows) that depends on no other files or installations. This eliminates the many complexities of building FFmpeg on platforms other than GNU/Linux; however you can still build it from source if you prefer.

Rationale

Casting complex objects from one type to another can be an uncomfortable process to express well. Objects that we use on a daily basis are not always in our control, and, even when they are, some don't lend themselves to simple construction. Remote service communication objects or complex data structures from libraries we use in our applications can result in large piles of casting code.

This circumstance often produces large swaths of procedural code, even if split up into separate function calls. This code can be not only difficult to understand, but difficult to test if an object requires a great deal of set up. Field or method assignments midway through can change and break the entire operation.

The goal of this project is to provide a method of defining easily digestible specifications for object translation that are also easily testable and changeable. The project focuses on writing specifications for transformations and not doing direct mutation in the recipes. The result is something that should seem somewhat functional, but also exceedingly separable.

Main Features

• The libraries use 63-bit addressing of array elements (all indexes and length are represented by 64-bit long type). So, it's theoretically possible to create and process arrays and matrices containing up to 2^63-1 (~10^19) elements of any primitive or non-primitive types, if OS and hardware can provide necessary amount of memory or disk space.

• Memory model concept allows storing AlgART arrays in different schemes, from simple Java arrays to mapped disk files; all necessary data transfers are performed automatically while every access to an element or a block of elements.

• Most of algorithms are based on wide usage of lazy evaluations. Typical operations, like elementwise summing or geometrical matrix transformations, are implemented via lazy views of the source array or matrix.

• • For example, you can take a multidimensional matrix, rotate it (or perform any other affine or projective transform), and then extract a submatrix from the result. All these operations will be performed virtually (not requiring time), and actual calculations will be performed only at the moment of accessing elements, usually while copying the resulting matrix to a newly created one. Moreover, in many cases the libraries will "understand" itself, that the user wants to perform rotation or another transform, and will split the matrix into suitable rectangular blocks (fitting in RAM) and choose the best algorithm for this task at the moment of copying operation.

• The libraries contain a wide set of image processing algorithms over matrices: linear filtering, mathematical morphology, rank operations, spectral transformation (FFT), etc.

• There is also skeletonization and measuring of binary images.

apel

• alist: utility for Association-list
• calist: utility for condition tree and condition/situation-alist
• filename: utility to make file-name
• install: utility to install emacs-lisp package
• mule-caeser: ROT 13-47-48 Caesar rotation utility
• path-util: utility for path management or file detection

emu

• broken: provide information of broken facilities of Emacs.
• invisible: provide features about invisible region
• mcharset: provide MIME charset related features
• pces: provide portable character encoding scheme features
• pccl: utility to write portable CCL program
• pcustom: provide portable custom environment
• poe: emulation module for basic functions and special forms/macros
• poem: provide basic functions to write portable MULE programs
• static: utility for static evaluation

Note

• enthought.appscripting: Framework for scripting applications.
• enthought.help: Provides a plugin for displaying documents and examples and running demos in Envisage Workbench applications.
• enthought.io: Provides an abstraction for files and folders in a file system.
• enthought.naming: Manages naming contexts, supporting non-string data types and scoped preferences.
• enthought.permissions: Supports limiting access to parts of an application unless the user is appropriately authorised (not full-blown security).
• enthought.persistence: Supports pickling the state of a Python object to a dictionary, which can then be flexibly applied in restoring the state of the object.
• enthought.preferences: Manages application preferences.
• enthought.resource: Manages application resources such as images and sounds.
• enthought.scripting: A framework for automatic recording of Python scripts.
• enthought.sweet_pickle: Handles class-level versioning, to support loading of saved data that exist over several generations of internal class structures.
• enthought.template: Supports creating templatizable object hierarchies.
• enthought.type_manager: Manages type extensions, including factories to generate adapters, and hooks for methods and functions.
• enthought.undo: Supports undoing and scripting application commands.