Portable Universal Resource Indentifier Library
Yet another URI library for Common Lisp
cl-routes is Common Lisp re-implementation of the Rails routes system for mapping URL's (also, see http://routes.groovie.org/)
Small library to make slugs, mainly for URIs, from english and beyond.
IDNA (international domain names) string encoding and decoding routines
Parse and print URLs as described in RFC 1738.
Facility for straightforward http routing on top of Hunchentoot.
An implementation of the URI Template proposed standard draft version 01.
dynamic html generation from list structures (interpolation friendly)
Hash table destructuring utils
David Lichteblau, Ivan ShvedunovLicense:
common-lisp.netproject/xuriella/Download (tarball): Yes, see belowDownload (git clone): git://repo.or.cz/xuriella.git
(gitweb)This project is asdf-installable (release tarball) and available in clbuild (git version).
An implementation of XSLT 1.0.
Feature overviewXuriella XSLT is an implementation of XSLT 1.0, written entirely in
Passes the XSLT 1.0 test suite
XSLT extension elements implementable in Common Lisp
Destructuring extension of LET*.
Base64 encoding and decoding with URI support.
The MD5 Message-Digest Algorithm RFC 1321
An efficient and portable implementation of the Fast Fourier Transform
CFFI bindings for curses.
CONSPACK implementation for Common Lisp
Runtime for cl-launch
The CL-RDFXML system provides functionality for processing RDF/XML
serializations of RDF graphs. RDF/XML processes XML using Closure XML
(CXML), and handles URIs using PURI.
evol - entrenched virtues of lisp / love reversed. Multi-purpose build system.
N-Dimensional Fourier Transforms
The GNU Scientific Library for Lisp (GSLL) allows you to use
the GNU Scientific
Library (GSL) from Common Lisp. This library provides a
full range of common mathematics operations useful to
scientific and engineering applications. The design of the GSLL
interface is such that access to most of the GSL library is
possible in a Lisp-natural way; the intent is that the user not
be hampered by the restrictions of the C language in which GSL
has been written. GSLL thus provides interactive use of GSL for
getting quick answers, even for someone not intending
to program in Lisp.
roots of polynomials, special functions, vector and matrix operations,
permutations, sorting, BLAS support, linear algebra,
eigensystems, fast Fourier transforms,
quadrature, random numbers, quasi-random sequences,
random distributions, statistics, histograms, N-tuples,
Monte Carlo integration, simulated annealing, differential
equations, interpolation, numerical differentiation,
chebyshev approximation, series acceleration,
discrete Hankel transforms, root-finding, minimization
least-squares fitting, IEEE floating-point,
discrete wavelet transforms.For more information see the project website.Available with Quicklisp.Page on GitLab
HTML-TEMPLATE is an HTML template library to use templates much like Perl's HTML::Template. Despite of its name, HTML-TEMPLATE is HTML-agnostic and could be used for templating other documents.It was written by Edi Weitz and can be found at http://weitz.de/html-template/.Jörg Höhle also liked the idea of a clear and complete
separation between HTML (written by designers) and code. He
came up with a variant of Edi's approach to HTML template. It uses
Edi's parsing code (thanks!), no more, but the programmer view on it
feels very different.Consider Edi's 7x7 chess board example on his documentation page and
how my code would look like:(setq my-template
;; load and check against specification
(tmpl-load "file.html" '((LOOP rows (LOOP cols colorful-style content)))))
(let ((counter 0))
(loop repeat 7 do
(loop repeat 7 do
(funcall cellprinter (oddp counter) (format nil "~R" counter))
Jörg Höhle's design goals:
Separate HTML design from code as much as possible, the key
idea in the template approach.
Verifiable specification of the interface between
both, never see "$foo" in a user's browser as an indication that
some variable was not substituted.
Designer and programmer work concurrently early
on. The programmer may use a default template automatically derived
from the specification, the web-designer a random-content template
delivering web-server based on this specification.
Efficiently deliver data, which should be no
slower than frameworks based on direct embedding of code in HTML or
vice-versa. That's why I rejected intermediate structures (Edi's template
structure) and produce compilable code. A parsed template
becomes Lisp code, which can be either compiled and loaded as such
from the file system, or compiled on the fly at load-time.
Incrementally deliver results as produced (useful
for huge data or HTTP 1.1 chunked encoding) which is incompatible
with non-lazy intermediate structures.
Provide for lexical scoping in templates,
unlike Perl's HTML::Template. That is, a TMPL_VAR occuring
inside TMPL_LOOP may refererence variables defined in an
outer (e.g. global) level. There's no need to repeat definitions at
Deliver data in pieces as large as posible: i.e. no individual
calls to PRINC or FORMAT for each HTML tag, coalesce these
Early HTML validation of the templates
some more I forgot...
[This next section confuses me a bit. I think a list entry refers to Edi's version, but I can't really tell.[
Some differences between Edi and Jörg's work include:
No facility for caching or automated reloading, which I feel
orthogonal to templates, interferes with
TMPL_INCLUDE and is left to the application.
An attempt to load templates validates them, so the running
web-server application will choose to reject template updates (and
log the error) until they are corrected instead of displaying
garbage to the user.
TMPL_VAR may have content, which is valuable for
the web designer's GUI: s/he sees this content up to a closing
Variable subtitution on the code side is based on ordering
in the specification, not on names or symbols, so there are no
surprises with packages and symbol-names across files.
The template substituting code is trivially small and was
ported to Scheme. In fact, there's almost no such code since it's
in part in the programmer calling sequence (witness the above
example) and part in the Lisp code representing the template.
Edi's got a package ready to go for you. [So is there code somewhere interested people could hack on, or something?]
The above specification is not all about the interface between
programmer and designer. URL structure, form names etc. need also
be agreed upon.
The template approach is very useable for
applications with small or medium demand for variable
appearance. Or you'd need too many templates.
I generated pages using templates featuring highly
dynamic content (e.g. variable numbers of both rows and
colums of a table, selectable and variable order) which some people
initially thought not usable with a strict templates approach. It
was, in fact, clean and easy.
TMPL_LOOP and TMPL_VAR are really
general and could even emulate TMPL_IF.
I generated my templates from Lisp code via SXML, instead of
having a designer. This aids consistency among templates. For a
all-by-one-person job, the separation is clear overhead, even if
there's potential for code reuse. You'd probably prefer a
HTML-from-sexpr approach in such a case and bypass templates.
HTML validation of the templates is hindered by
TMPL_IF with an ELSE part, substitutions
inside attributes and obviously only possible when the
substitutions done by TMPL_VAR affect the HTML
structure. The most dynamic template is TMPL_VAR
As an enhancement, there could be a mechanism for global
substitutions which would remain outside of the specification.
E.g. some pages like to display calendars, the current date or use
a mapping from month names to numbers etc. Such substitutions could
always be present, across all pages of the application.
Hunchensocket is a Common Lisp implementation of WebSockets realized as an extension to Edi Weitz' excellent Hunchentoot web server.As WebSockets are still in draft state and security concerns have been raised against older (but supported) draft versions of the protocol implemented in a number of browsers, it should not be used productively (yet), unless of course you know what you're doing.Categories: Web, IPC, WebSocket serverAuthor: Alexander KahlSource repository: https://github.com/capitaomorte/hunchensocket.
An essential part of any general chemistry program is the periodic table of the elements. Nobody wants to copy the whole thing by hand, and figuring out how to represent it can be a minor headache. Therefore, you should download the periodic-table Library. It is fully asdf-installable and has been tested without any problems on SBCL and LispWorks.The home page is
;; Get the name of the element which has the symbol "Kr"
(element-name (symbol-element "Kr")) => "Krypton"
;; It isn't case sensitive
(element-name (symbol-element "kR")) => "Krypton"
;; Find the element with the electronegativity closest to 4.0
;; Get an element from its atomic number
(element-symbol (get-element 12)) => "Mg"
;; Demonstrate another use of the powerful GET-ELEMENT function.
;; Boiling point is in Kelvins
(element-boiling-point (get-element 'nitrogen)) => 77.344It is released under the LLGPL.
Nondeterministic programming and constraint propagation.
STMX is an actively maintained, high-performance concurrency library providing Transactional Memory for Common Lisp.Home page and downloads: http://github.com/cosmos72/stmx Main features
Extremely intuitive to use and to write correct, thread-safe concurrent code
Brings database-style transactions to Common Lisp by introducing transactional memory
High performance implementation, benchmarked to exceed 7 millions transactions per CPU core per second on commodity PC hardware
Support for hardware memory transactions (requires 64-bit SBCL and CPUs with Intel TSX instructions - currently Core i5 4570, Core i7 4670, Core i7 4770 and some others). They increase STMX performance up to almost 40 millions transactions per CPU core per second
Removes the need for traditional locks, mutexes and conditions - writing correct concurrent code with them is well known to be hard
Transactional code is intrinsically deadlock-free: if two transactions conflict one of them will be re-executed
Automatic commit and rollback: if a transaction completes normally it will be committed, if it signals an error it will be rolled back
Transactions are composable: they can be executed in a larger transaction, either in sequence (all-or-nothing) or as alternatives (try them until one succeeds)
Offers freedom of choice between blocking and non-blocking transactional functions: given either behaviour, it is trivial to transform it into the other.
Features transactional versions of popular data structures: hash tables, red-black trees, stack, fifo
Includes transactional data structure for multicast publish/subscribe
Creating new transactional data structures is easy
Extensive test suite
Tested on SBCL, ABCL, CCL, CMUCL and ECL.
Very simple to install with Quicklisp
A quick-start guide and installation instructions are provided in README.md fileLicense: LLGPL What STMX is NOT
In order not to confuse programmers - less experienced ones in particular - and to avoid rising unrealistic hopes, the author himself stated the following about STMX:
it is NOT a quick hack to automagically transform existing, slow, single-threaded programs into fast, concurrent ones. No matter how much transactions can help, writing concurrent code still requires careful design and implementation - and testing. And refactoring takes time too.
it is NOT for optimization-focused programmers trying to squeeze the last cycle from their Common Lisp programs. STMX records an in-memory transaction log containing all reads and writes from/to transactional memory, then later (during commit) validates the transaction log against the latest data present in transactional memory and finally copies the transaction log onto the transactional memory while holding locks. STMX is quite optimized, but this machinery comes at an obvious performance cost with respect to hand-made, highly optimized locking code (but a good reality check is to ask yourself how many people have the skill and patience to write such code without bugs).
it is NOT supposed to be used for all data structures in a Common Lisp program. STMX is intended only for the data accessed concurrently by multiple threads while being modified by at least one thread. And even in that case, transactional memory is not always needed: it depends on the kinds of modifications.
it is NOT a serialization or persistence framework. Rather, messing with metaclasses and playing (allowed) tricks with slots contents as STMX does, quite likely does not mix well with serialization or persistence libraries such as CL-STORE, because they typically need full control on the slots of the objects to be serialized and de-serialized.
it is NOT a million dollar library from some deep-pocket company. At the moment, it is the work of a single person.
A tiling, keyboard driven window manager