This Common Lisp package offers functions for parsing and formatting decimal numbers. The package's main interface are the functions parse-decimal-number and format-decimal-number. The former is for parsing strings for decimal numbers and the latter for pretty-printing them as strings.

Radiance is a web application environment, which is sort of like a web framework, but more general, more flexible. It should let you write personal websites and generally deployable applications easily and in such a way that they can be used on practically any setup without having to undergo special adaptations.

This is a client library to interact with the "mod.io" (https://mod.io) platform to manage "mods" or extensions for games and other applications. It covers the full v1 API and includes convenience methods to make interacting with the API as well as syncing mods and so on easy.

FARE-MOP is a small collection of utilities using the MetaObject Protocol. It notably contains a SIMPLE-PRINT-OBJECT method, and a SIMPLE-PRINT-OBJECT-MIXIN mixin that allow you to trivially define PRINT-OBJECT methods that print the interesting slots in your objects, which is great for REPL interaction and debugging.

ContextL is a CLOS extension for Context-Oriented Programming (COP).

Find overview of ContextL's features in an overview paper: http://www.p-cos.net/documents/contextl-soa.pdf. See also this general overview article about COP which also contains some ContextL examples: http://www.jot.fm/issues/issue_2008_03/article4/.

Sycamore is a fast, purely functional data structure library in Common Lisp. If features:

• Fast, purely functional weight-balanced binary trees.

• Leaf nodes are simple-vectors, greatly reducing tree height.

• Interfaces for tree Sets and Maps (dictionaries).

• Ropes.

• Purely functional pairing heaps.

• Purely functional amortized queue.

Magic (ed) is a tiny editing facility for Common Lisp, where you can directly load, edit, manipulate and evaluate file or file content from REPL. This package also can be a starting point for people who are not accustomed to Emacs or SLIME and would like to continue using their default terminal/console editor with Common Lisp.

This library implements the let+ macro, which is a dectructuring extension of let*. It features:

• Clean, consistent syntax and small implementation (less than 300 LOC, not counting tests)

• Placeholder macros allow editor hints and syntax highlighting

• &ign for ignored values (in forms where that makes sense)

• Very easy to extend

Eclector is a portable Common Lisp reader that is highly customizable, can recover from errors and can return concrete syntax trees.

In contrast to many other reader implementations, eclector can recover from most errors in the input supplied to it and continue reading. This capability is realized as a restart.

It can also produce instances of the concrete syntax tree classes provided by the concrete syntax tree library.

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.

Virality Engine provides a system and workflow that helps describe the elements needed to write 2D or 3D games. It was designed with several domain specific languages that make it easier to describe, manipulate, and use assets commonly found in game making. Such assets include (but are not limited to) textures, materials, shader programs, and scene trees of actors that are available for instantiation. Virality Engine also knows how to accept input from keyboards and most joysticks and gamepads.

The component system is a hybrid model between an ECS and an object model. The components are defined similar to CLOS defclass, and regular generic methods can be used with them. Components are added to Actors which represent game concepts like players, scenery, effects, etc. We define a component protocol invoked by Virality Engine to move your components to the next state and render them each frame.

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.

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.