This is a wrapper for the SDL2_TTF library used for loading fonts and creating text assets. The library, in it's current state, can load TTF and OTF fonts and render fonts with the three different rendering modes provided by the C library (solid, shaded, and blended). While Latin text, UTF8, UNICODE, and Glyph text rendering is available only Latin text has been tested (as shown in the examples).

This package provides CFFI binding to libmixed audio library for Common Lisp with support of other audio formats available on GNU/Linux systems:

• Alsa

• Jack

• Openmpt

• PulseAudio

• Flac (via CL-FLAC)

• Mpg123 (via CL-MPG123)

• Ogg/vorbis (via CL-VORBIS)

• Out123 (via CL-OUT123)

• WAV

binascii is a Common Lisp library for converting binary data to ASCII text of some kind. Such conversions are common in email protocols (for encoding attachments to support old non-8-bit clean transports) or encoding binary data in HTTP and XML applications. binascii supports the encodings described in RFC 4648: base64, base32, base16, and variants. It also supports base85, used in Adobe's PostScript and PDF document formats, and a variant called ascii85, used by git for binary diff files.

Overlord is a build system in Common Lisp. It is a real build system, with all the modern features: rules with multiple outputs, parallel builds, immunity to clock issues, and dynamic dependencies.

But Overlord is more than another build system. Overlord is a uniform approach to dependencies inside or outside of a Lisp image. Overlord is to Make what Lisp macros are to C macros.

Overlord is designed to be used from the Lisp REPL. A command line interface is available in a separate repository. See https://github.com/ruricolist/overlord-cli.

Screamer is an extension of Common Lisp that adds support for nondeterministic programming. Screamer consists of two levels. The basic nondeterministic level adds support for backtracking and undoable side effects. On top of this nondeterministic substrate, Screamer provides a comprehensive constraint programming language in which one can formulate and solve mixed systems of numeric and symbolic constraints. Together, these two levels augment Common Lisp with practically all of the functionality of both Prolog and constraint logic programming languages such as CHiP and CLP(R). Furthermore, Screamer is fully integrated with Common Lisp. Screamer programs can coexist and interoperate with other extensions to as CLIM and Iterate.

Nsymbols extends the regular package API of ANSI CL with more operations, allowing one to list:

• package-symbols.

• package-variables.

• package-functions.

• package-generic-functions.

• package-macros.

• package-classes.

• package-structures.

• And other symbol types, given define-symbol-type for those.

Nsymbols can also find symbols by their name/matching symbol with resolve-symbol. All these operations are aware of symbol visibility in the given packages, due to a symbol-visibility function.

An additional nsymbols/star system has a set of functions mirroring the regular Nsymbols ones, but using closer-mop to provide better results and returning structured data instead of symbols.

common lisp/cffi bindings for Open Asset Import Library (http://assimp.sourceforge.net/)

Should support assimp versions 3.0 to 3.3.x. Version to support is determined by querying c library at compile time (or load if not previously compiled), with errors if versions don't match at load or runtime. (Current assimp from git will be detected as 3.3, but isn't completely binary compatible so might have problems)

Allows (among other things) loading of the following formats:

Collada ( .dae ) Blender 3D ( .blend ) 3ds Max 3DS ( .3ds ) 3ds Max ASE ( .ase ) Wavefront Object ( .obj ) Industry Foundation Classes (IFC/Step) ( .ifc ) XGL ( .xgl,.zgl ) Stanford Polygon Library ( .ply ) *AutoCAD DXF ( .dxf ) LightWave ( .lwo ) LightWave Scene ( .lws ) Modo ( .lxo ) Stereolithography ( .stl ) DirectX X ( .x ) AC3D ( .ac ) Milkshape 3D ( .ms3d ) * TrueSpace ( .cob,.scn )

cl-tar-file is a Common Lisp library that allows reading from and writing to various tar archive formats. Currently supported are the POSIX ustar, PAX (ustar with a few new entry types), GNU, and v7 (very old) formats.

This library is rather low level and is focused exclusively on reading and writing physical tar file entries using streams. Therefore, it contains no functionality for automatically building archives from a set of files on the filesystem or writing the contents of a file to the filesystem. Additionally, there are no smarts that read multiple physical entries and combine them into a single logical entry (e.g., with PAX extended headers or GNU long link/path name support). For a higher-level library that reads and writes logical entries, and also includes filesystem integration, see cl-tar.

Calispel is a Common Lisp library for thread-safe message-passing channels, in the style of the occam programming language, also known as communicating sequential processes (CSP). See https://en.wikipedia.org/wiki/Communicating_sequential_processes.

Calispel channels let one thread communicate with another, facilitating unidirectional communication of any Lisp object. Channels may be unbuffered, where a sender waits for a receiver (or vice versa) before either operation can continue, or channels may be buffered with flexible policy options.

Because sending and receiving on a channel may block, either operation can time out after a specified amount of time.

A syntax for alternation is provided (like ALT in occam, or Unix select()): given a sequence of operations, any or all of which may block, alternation selects the first operation that doesn't block and executes associated code. Alternation can also time out, executing an "otherwise" clause if no operation becomes available within a set amount of time.

Calispel is a message-passing library, and as such leaves the role of threading abstractions and utilities left to be filled by complementary libraries such as Bordeaux-Threads and Eager Future.

A hook, in the present context, is a certain kind of extension point in a program that allows interleaving the execution of arbitrary code with the execution of a the program without introducing any coupling between the two. Hooks are used extensively in the extensible editor Emacs.

In the Common LISP Object System (CLOS), a similar kind of extensibility is possible using the flexible multi-method dispatch mechanism. It may even seem that the concept of hooks does not provide any benefits over the possibilities of CLOS. However, there are some differences:

• There can be only one method for each combination of specializers and qualifiers. As a result this kind of extension point cannot be used by multiple extensions independently.

• Removing code previously attached via a :before, :after or :around method can be cumbersome.

• There could be other or even multiple extension points besides :before and :after in a single method.

• Attaching codes to individual objects using eql specializers can be cumbersome.

• Introspection of code attached a particular extension point is cumbersome since this requires enumerating and inspecting the methods of a generic function.

This library tries to complement some of these weaknesses of method-based extension-points via the concept of hooks.

This is a keymap facility for Common Lisp inspired by Emacsy (keymap.scm) which is inspired by Emacs.

• Support prefix keys to other keymaps. For instance, if you prefix my-mode-map with C-c, then all bindings for my-mode will be accessible after pressing C-c.

• List all bindings matching a given prefix. (Also known as which-key in Emacs.)

• List the bindings associated to a command.

• Support multiple inheritance.

• Support keycode.

• Validate keyspec at compile time.

• define-key can set multiple bindings in a single call.

• Support multiple scheme to make it easy to switch between, say, Emacs-style and VI-style bindings. This orthogonality to keymaps composes better than having multiple keymaps: changing scheme applies to the entire program, which is easier than looping through all keymaps to change them.

• Translate keyspecs as a fallback. For instance if shift-a is not bound, check A.

• Behaviour can be customized with global parameters such as *print-shortcut*.

• The compose function can merge multiple keymaps together.

• Support multiple arguments when that makes sense (e.g. multiple keymaps for lookup-key).

• Key remapping à-la Emacs.

• Typed keymaps, i.e. keymaps where bound values can only be of a given type. This is convenient to catch typos, for instance when binding 'FOO instead of #'FOO.

This is a keymap facility for Common Lisp inspired by Emacsy (keymap.scm) which is inspired by Emacs.

• Support prefix keys to other keymaps. For instance, if you prefix my-mode-map with C-c, then all bindings for my-mode will be accessible after pressing C-c.

• List all bindings matching a given prefix. (Also known as which-key in Emacs.)

• List the bindings associated to a command.

• Support multiple inheritance.

• Support keycode.

• Validate keyspec at compile time.

• define-key can set multiple bindings in a single call.

• Support multiple scheme to make it easy to switch between, say, Emacs-style and VI-style bindings. This orthogonality to keymaps composes better than having multiple keymaps: changing scheme applies to the entire program, which is easier than looping through all keymaps to change them.

• Translate keyspecs as a fallback. For instance if shift-a is not bound, check A.

• Behaviour can be customized with global parameters such as *print-shortcut*.

• The compose function can merge multiple keymaps together.

• Support multiple arguments when that makes sense (e.g. multiple keymaps for lookup-key).

• Key remapping à-la Emacs.

• Typed keymaps, i.e. keymaps where bound values can only be of a given type. This is convenient to catch typos, for instance when binding 'FOO instead of #'FOO.

Common Lisp comes with quite some functions to compare objects for equality, yet none is applicable in every situation and in general this is hard, as equality of objects depends on the semantics of operations on them. As consequence, users find themselves regularly in a situation where they have to roll their own specialized equality test.

This module provides one of many possible equivalence relations between standard Common Lisp objects. However, it can be extended for new objects through a simple CLOS protocol. The rules when two objects are considered equivalent distinguish between mutating and frozen objects. A frozen object is promised not to be mutated in the future in a way that operations on it can notice the difference.

We have chosen to compare mutating objects only for identity (pointer equality), to avoid various problems. Equivalence for frozen objects on the other hand is established by recursing on the objects' constituent parts and checking their equivalence. Hence, two objects are equivalent under the OBJECT= relation, if they are either identical, or if they are frozen and structurally equivalent, i.e. their constituents are point-wise equivalent.

Since many objects are potentially mutable, but are not necessarily mutated from a certain point in their life time on, it is possible to promise to the equivalence relation that they remain frozen for the rest of their life time, thus enabling coarser equivalence than the often too fine-grained pointer equality.

Package that let's sdl2 host cepl

Implementation of a base16 builder for lisp

This is a unit-testing framework for Common Lisp.

cl-gendoc is a simple component-based documentation generator.

This package provides a statistical computing environment for Common Lisp.

CL-SYNTAX provides Reader Syntax Conventions for Common Lisp and SLIME.

hdf5-cffi is a CFFI wrapper for the HDF5 library.

This package provides Common Lisp FFI bindings for xkbcommon (libxkbcommon) using cffi-grovel.

This is a Common Lisp library that implements the 9p network filesystem protocol.