Planet Lisp
http://planet.lisp.org/
Planet LispenABCL Dev: Turning the Bear past Java 11http://abcl-dev.blogspot.com/2019/11/turning-bear-past-java-11.html
http://abcl-dev.blogspot.com/2019/11/turning-bear-past-java-11.html
<div dir="ltr"><span>As the leaves fall in the Northern hemisphere, thoughts of the Bear<br />turn to a rumored permanent slumber, and a complete absence of the<br />possibility of new updates. The Bear <a href="https://abcl.org/trac/" target="_blank">reviews</a> all <a href="https://gitlab.common-lisp.net/abcl/abcl/" target="_blank">submitted</a> <br /><a href="https://github.com/armedbear/abcl/" target="_blank">patches</a>, so if you don't like the current implementation,<br />please get out and push. Or pull? Or fast forward? The Bear is<br />seemingly always confused with Git...<br /><br />As previously rumored, <a href="https://github.com/armedbear/abcl/commit/a628e961a1dc33e1f225191a19494701d7770e55" target="_blank">patches for getting the Armed Bear</a></span><br /><span>Common Lisp implementation running on Java 11 have landed in<br />the <a href="https://abcl.org/trac/changeset/15133" target="_blank">trunk</a>.<br /><br />Unless anyone objects strongly, we will release <a href="https://abcl.org/trac/milestone/1.6.0">ABCL 1.6.0</a> as soon </span><br /><span>as possible with the intention to support the openjdk{6,7,8,11} runtimes.<br /><br />After stabilizing the 1.6 branch with the inevitable necessary and<br />unknown updates, we can turn our attention to the <a href="https://abcl.org/trac/milestone/2.0.0">ABCL 2.0 branch</a> which <br />will introduce support for additional runtimes but drop support for emitting </span><br /><span>openjdk6 or openjdk7 compatible byte-code.<br /><br />Stay tuned, Bear fans...</span></div>Thu, 14 Nov 2019 14:29:00 GMTLispers.de: Lisp-Meetup in Hamburg on Monday, 4th November 2019https://www.lispers.de/#2019-11-01-Hamburg
https://www.lispers.de/#2019-11-01-Hamburg
<p class="content">We meet at Ristorante Opera, Dammtorstraße 7, Hamburg, starting around 19:00 CEST on 4th November 2019.</p><p class="content">This is an informal gathering of Lispers of all experience levels.</p><p class="content">Topics might include Advent of Code, Lisp jobs, cryptography, event sourcing.</p>Fri, 01 Nov 2019 00:00:00 GMTEugene Zaikonnikov: Yocto recipe for CLISPhttp://blog.funcall.org//lisp/2019/10/28/yocto-clisp/
http://blog.funcall.org//lisp/2019/10/28/yocto-clisp/
<p>Some time ago I put together a simple <a href="https://github.com/varjagg/recipes-lisp">recipe for building CLISP</a> with <a href="https://www.yoctoproject.org">Yocto</a>. It is pinned to 2.49.93 and should work both for target and -native builds. Tested with Sumo only.</p>Sun, 27 Oct 2019 15:00:00 GMTVsevolod Dyomkin: Programmatically Drawing Simple Graphviz Graphshttp://lisp-univ-etc.blogspot.com/2019/10/programmatically-drawing-simple.html
http://lisp-univ-etc.blogspot.com/2019/10/programmatically-drawing-simple.html
<p>For <a href="https://gist.github.com/vseloved/915a2aad64bddfae8376e0b1b4ca29aa">my book</a>, I had to draw a number of graphs. Obviously, I wanted to have a programmatic way to do that, and Graphviz is the goto-library for that. In Lisp, the interface to Graphviz is <a href="http://www.foldr.org/~michaelw/projects/cl-dot/">cl-dot</a>, but, for me, it wasn't easy to figure out from the manual the "simple and easy" way to use it. I.e. I couldn't find a stupid beginner-level interface, so I had to code it myself. Here's the implementation that allows anyone with a REPL to send to Graphviz lists of edges and obtain graph images.</p> <p>Generated images:</p> <div class="separator"><a href="https://1.bp.blogspot.com/-rd2h-P3xDxI/XbLTq6mLEnI/AAAAAAAACOc/gLmrlXfrLXMHCunu8OPVLGLfQcXCctjzQCLcBGAsYHQ/s1600/max-flow-graph.jpg"><img border="0" src="https://1.bp.blogspot.com/-rd2h-P3xDxI/XbLTq6mLEnI/AAAAAAAACOc/gLmrlXfrLXMHCunu8OPVLGLfQcXCctjzQCLcBGAsYHQ/s1600/max-flow-graph.jpg" /></a></div><div class="separator"><a href="https://3.bp.blogspot.com/-Q_TABCIyEBQ/XbLTjZsFsNI/AAAAAAAACOY/iaL0XfAjn_szYXnts69yN30kU-8gPZg6gCLcBGAsYHQ/s1600/g.jpg"><img border="0" src="https://3.bp.blogspot.com/-Q_TABCIyEBQ/XbLTjZsFsNI/AAAAAAAACOY/iaL0XfAjn_szYXnts69yN30kU-8gPZg6gCLcBGAsYHQ/s1600/g.jpg" /></a></div>Fri, 25 Oct 2019 10:48:00 GMTVsevolod Dyomkin: Programming Algorithms: Graphshttp://lisp-univ-etc.blogspot.com/2019/10/programming-algorithms-graphs.html
http://lisp-univ-etc.blogspot.com/2019/10/programming-algorithms-graphs.html
<p>Graphs have already been mentioned several times, in the book, in quite diverse contexts. Actually, if you are familiar with graphs you can spot opportunities to use them in quite different areas for problems that aren't explicitly formulated with graphs in mind. So, in this chapter, we'll discuss how to handle graphs to develop such intuition to some degree.</p> <p>But first, let's list the most prominent examples of the direct graph applications, some of which we'll see here in action:</p> <ul><li>pathfinding</li><li>network analysis</li><li>dependency analysis in planning, compilers, etc.</li><li>various optimization problems</li><li>distributing and optimizing computations</li><li>knowledge representation and reasoning with it</li><li>meaning representation in natural language processing</li></ul> <p>Graphs may be thought of as a generalization of trees: indeed, trees are, as we said earlier, connected directed acyclic graphs. But there's an important distinction in the patterns of the usage of graphs and trees. Graphs, much more frequently than trees, have weights associated with the edges, which adds a whole new dimension both to algorithms for processing them and to possible data that can be represented in the graph form. So, while the main application of trees is reflecting some hierarchy, for graphs, it is often more about determining connectedness and its magnitude, based on the weights.</p> <h2 id="graphrepresentations">Graph Representations</h2> <p>A graph is, basically, a set of nodes (called "vertices", <code>V</code>) and an enumeration of their pairs ("edges", <code>E</code>). The edges may be directed or undirected (i.e. bidirectional), and also weighted or unweighted. There are many ways that may be used to represent these sets, which have varied utility for different situations. Here are the most common ones:</p> <ul><li>as a linked structure: <code>(defstruct node data links)</code> where <code>links</code> may be either a list of other <code>node</code>s, possibly, paired with weights, or a list of <code>edge</code> structures represented as <code>(defsturct edge source destination weight)</code>. For directed graphs, this representation will be similar to a singly-linked list but for undirected — to a heavier doubly-linked one</li><li>as an adjacency matrix (<code>V x V</code>). This matrix is indexed by vertices and has zeroes when there's no connection between them and some nonzero number for the weight (1 — in case of unweighted graphs) when there is a connection. Undirected graphs have a symmetric adjacency matrix and so need to store only the abovediagonal half of it</li><li>as an adjacency list that enumerates for each vertex the other vertices it's connected to and the weights of connections</li><li>as an incidence matrix (<code>V x E</code>). This matrix is similar to the previous representation, but with much more wasted space. The adjacency list may be thought of as a sparse representation of the incidence matrix. The matrix representation may be more useful for hypergraphs (that have more than 2 vertices for each edge), though</li><li>just as a list of edges</li></ul> <h2 id="topologicalsort">Topological Sort</h2> <p>Graphs may be divided into several kinds according to the different properties they have and specific algorithms, which work on them:</p> <ul><li>disjoint (with several unconnected subgraphs), connected, and fully-connected (every vertex is linked to all the others)</li><li>cyclic and acyclic, including directed acyclic (DAG)</li><li>bipartite: when there are 2 groups of vertices and each vertex from one group is connected only to the vertices from the other</li></ul> <p>In practice, <strong>Directed Acyclic Graphs</strong> are quite important. These are directed graphs, in which there's no vertex that you can start a path from and return back to it. They find applications in optimizing scheduling and computation, determining historical and other types of dependencies (for example, in dataflow programming and even spreadsheets), etc. In particular, every compiler would use one and even <code>make</code> will when building the operational plan. The basic algorithm on DAGs is <strong>Topological sort</strong>. It creates a partial ordering of the graph's vertices which ensures that every child vertex is always preceding all of its ancestors.</p> <p>Here is an example. This is a DAG:</p> <img border="0" src="https://1.bp.blogspot.com/-HCu7HDd2hTw/XbFzkugDFDI/AAAAAAAACNk/JBJfk9o9sdMKu7xLFn0h1FR7A9D_dle9ACPcBGAYYCw/s400/graph-topo.png" width="400" height="170" /> <p>And these are the variants of its topological ordering:</p> <pre><code>6 4 5 3 2 1 8 7<br />6 4 5 2 3 1 8 7<br />8 7 6 4 5 3 2 1<br />8 7 6 4 5 2 3 1<br /></code></pre> <p>There are several variants as the graph is disjoint, and also the order in which the vertices are traversed is not fully deterministic.</p> <p>There are two common approaches to topological sort: the Kahn's algorithm and the DFS-based one. Here is the DFS version:</p> <ol><li>Choose an arbitrary vertex and perform the DFS from it until a vertex is found without children that weren't visited during the DFS.</li><li>While performing the DFS, add each vertex to the set of visited ones. Also check that the vertex hasn't been visited already, or else the graph is not acyclic.</li><li>Then, add the vertex we have found to the resulting sorted array.</li> <li>Return to the previous vertex and repeat searching for the next descendant that doesn't have children and add it.</li><li>Finally, when all of the current vertex's children are visited add it to the result array.</li><li>Repeat this for the next unvisited vertex until no unvisited ones remain.</li></ol> <p>Why does the algorithm satisfy the desired constraints? First of all, it is obvious that it will visit all the vertices. Next, when we add the vertex we have already added all of its descendants — satisfying the main requirement. Finally, there's a consistency check during the execution of the algorithm that ensures there are no cycles.</p> <p>Before proceeding to the implementation, as with other graph algorithms, it makes sense to ponder what representation will work the best for this problem. The default one — a linked structure — suits it quite well as we'll have to iterate all the outgoing edges of each node. If we had to traverse by incoming edges then it wouldn't have worked, but a matrix one would have.</p> <pre><code>(defstruct node<br /> id edges)<br /><br />(defstruct edge<br /> src dst label)<br /><br />(defstruct (graph (:conc-name nil) (:print-object pprint-graph))<br /> (nodes (make-hash-table))) ; mapping of node ids to nodes<br /></code></pre> <p>As usual, we'll need a more visual way to display the graph than the default print-function. But that is pretty tricky considering that graphs may have an arbitrary structure with possibly intersecting edges. The simplest approach for small graphs would be to just draw the adjacency matrix. We'll utilize it for our examples (relying on the fact that we have control over the set of node ids):</p> <pre><code>(defun pprint-graph (graph stream)<br /> (let ((ids (sort (keys (nodes graph)) '<)))<br /> (format stream "~{ ~A~}~%" ids) ; here, Tab is used for space<br /> (dolist (id1 ids)<br /> (let ((node (? graph 'nodes id1)))<br /> (format stream "~A" id1)<br /> (dolist (id2 ids)<br /> (format stream " ~:[~;x~]" ; here, Tab as well<br /> (find id2 (? node 'edges) :key 'edge-dst)))<br /> (terpri stream)))))<br /></code></pre> <p>Also, let's create a function to simplify graph initialization:</p> <pre><code>(defun init-graph (edges)<br /> (with ((rez (make-graph))<br /> (nodes (nodes rez)))<br /> (loop :for (src dst) :in edges :do<br /> (let ((src-node (getset# src nodes (make-node :id src))))<br /> (getset# dst nodes (make-node :id dst))<br /> (push (make-edge :src src :dst dst)<br /> (? src-node 'edges))))<br /> rez))<br /><br />CL-USER> (init-graph '((7 8)<br /> (1 3)<br /> (1 2)<br /> (3 4)<br /> (3 5)<br /> (2 4)<br /> (2 5)<br /> (5 4)<br /> (5 6)<br /> (4 6)))<br /><br /> 1 2 3 4 5 6 7 8<br />1 x x <br />2 x x <br />3 x x <br />4 x <br />5 x x <br />6 <br />7 x<br />8 <br /></code></pre> <p>So, we already see in action 3 different ways of graphs representation: linked, matrix, and edges lists.</p> <p>Now, we can implement and test topological sort:</p> <pre><code>(defun topo-sort (graph)<br /> (let ((nodes (nodes graph))<br /> (visited (make-hash-table))<br /> (rez (vec)))<br /> (dokv (id node nodes)<br /> (unless (? visited id)<br /> (visit node nodes visited rez)))<br /> rez))<br /><br />(defun visit (node nodes visited rez)<br /> (dolist (edge (? node 'edges))<br /> (with ((id (? edge 'dst))<br /> (child (? nodes id)))<br /> (unless (find id rez)<br /> (assert (not (? visited id)) nil<br /> "The graph isn't acyclic for vertex: ~A" id)<br /> (:= (? visited id) t)<br /> (visit child nodes visited rez))))<br /> (vector-push-extend (? node 'id) rez)<br /> rez)<br /><br />CL-USER> (topo-sort (init-graph '((7 8)<br /> (1 3)<br /> (1 2)<br /> (3 4)<br /> (3 5)<br /> (2 4)<br /> (2 5)<br /> (5 4)<br /> (5 6)<br /> (4 6))))<br />#(8 7 6 4 5 2 3 1)<br /></code></pre> <p>This technique of tracking the visited nodes is used in almost every graph algorithm. As noted previously, it can either be implemented using an additional hash-table (like in the example) or by adding a boolean flag to the vertex/edge structure itself.</p> <h2 id="mst">MST</h2> <p>Now, we can move to algorithms that work with weighted graphs. They represent the majority of the interesting graph-based solutions. One of the most basic of them is determining the Minimum Spanning Tree. Its purpose is to select only those graph edges that form a tree with the lowest total sum of weights. Spanning trees play an important role in network routing where there is a number of protocols that directly use them: STP (Spanning Tree Protocol), RSTP (Rapid STP), MSTP (Multiple STP), etc.</p> <p>If we consider the graph from the previous picture, its MST will include the edges 1-2, 1-3, 3-4, 3-5, 5-6, and 7-8. Its total weight will be 24.</p> <p>Although there are quite a few MST algorithms, the most well-known are Prim's and Kruskal's. Both of them rely on some interesting solutions and are worth studying.</p> <h3 id="primsalgorithm">Prim's Algorithm</h3> <p>Prim's algorithm grows the tree one edge at a time, starting from an arbitrary vertex. At each step, the least-weight edge that has one of the vertices already in the MST and the other one outside is added to the tree. This algorithm always has an MST of the already processed subgraph, and when all the vertices are visited, the MST of the whole graph is completed. The most interesting property of Prim's algorithm is that its time complexity depends on the choice of the data structure for ordering the edges by weight. The straightforward approach that searches for the shortest edge will have <code>O(V^2)</code> complexity, but if we use a priority queue it can be reduced to <code>O(E logV)</code> with a binary heap or even <code>O(E + V logV)</code> with a Fibonacci heap. Obviously, <code>V logV</code> is significantly smaller than <code>E logV</code> for the majority of graphs: up to <code>E = V^2</code> for fully-connected graphs.</p> <p>Here's the implementation of the Prim's algorithm with an abstract heap:</p> <pre><code>(defun prim-mst (graph)<br /> (let ((initial-weights (list))<br /> (mst (list))<br /> (total 0)<br /> weights<br /> edges<br /> cur)<br /> (dokv (id node (nodes graph))<br /> (if cur<br /> (push (pair id (or (? edges id)<br /> ;; a standard constant that is<br /> ;; a good enough substitute for infinity<br /> most-positive-fixnum))<br /> initial-weights)<br /> (:= cur id<br /> edges (? node 'edges))))<br /> (:= weights (heapify initial-weights))<br /> (loop<br /> (with (((id weight) (heap-pop weights)))<br /> (unless id (return))<br /> (when (? edges id)<br /> ;; if not, we have moved to the new connected component<br /> ;; so there's no edge connecting it to the previous one<br /> (push (pair cur id) mst)<br /> (:+ total weight))<br /> (dokv (id w edges)<br /> (when (< w weight)<br /> (heap-decrease-key weights id w)))<br /> (:= cur id<br /> edges (? graph 'nodes id 'edges))))<br /> (values mst<br /> total)))<br /></code></pre> <p>To make it work, we need to perform several modifications:</p> <ul><li>first of all, the list of all node edges should be change to a hash-table to ensure <code>O(1)</code> access by child id</li> <li>the heap should store not only the keys but also values (a trivial change)</li> <li>we need to implement another fundamental heap operation <code>heap-decrease-key</code>, which we haven't mentioned in the previous chapter</li></ul> <p>For the binary heap, it's, actually, just a matter of performing <code>heap-up</code>. But the tricky part is that it requires an initial search for the key. To ensure constant-time search and, subsequently, <code>O(log n)</code> total complexity, we need to store the pointers to heap elements in a separate hash-table.</p> <p>Let's confirm the stated complexity of this implementation? First, the outer loop operates for each vertex so it has <code>V</code> iterations. Each iteration has an inner loop that involves a <code>heap-pop</code> (<code>O(log V)</code>) and a <code>heap-update</code> (also <code>O(log V)</code>) for a number of vertices, plus a small number of constant-time operations. <code>heap-pop</code> will be invoked exactly once per vertex, so it will need <code>O(V logV)</code> total operations, and <code>heap-update</code> will be called at most once for each edge (<code>O(E logV)</code>). Considering that <code>E</code> is usually greater than <code>V</code>, this is how we can arrive at the final complexity estimate.</p> <p>The Fibonacci heap improves on the binary heap, in this context, as its <code>decrease-key</code> operation is <code>O(1)</code> instead of <code>O(log V)</code>, so we are left with just <code>O(V logV)</code> for <code>heap-pop</code>s and <code>E</code> <code>heap-decrease-key</code>s. Unlike the binary heap, the Fibonacci one is not just a single tree but a set of trees. And this is used in decrease-key: instead of popping an item up the heap and rearranging it in the process, a new tree rooted at this element is cut from the current one. This is not always possible in constant time as there are some invariants that might be violated, which will in turn trigger some updates to the newly created two trees. Yet, using an amortized cost of the operation is still <code>O(1)</code>.</p> <p>Here's a brief description of the principle behind the Fibonacci heap adapted from Wikipedia:</p> <p>A Fibonacci heap is a collection of heaps. The trees do not have a prescribed shape and, in the extreme case, every element may be its own separate tree. This flexibility allows some operations to be executed in a lazy manner, postponing the work for later operations. For example, merging heaps is done simply by concatenating the two lists of trees, and operation decrease key sometimes cuts a node from its parent and forms a new tree. However, at some point order needs to be introduced to the heap to achieve the desired running time. In particular, every node can have at most <code>O(log n)</code> children and the size of a subtree rooted in a node with <code>k</code> children is at least <code>F(k+2)</code>, where <code>F(k)</code> is the <code>k</code>-th Fibonacci number. This is achieved by the rule that we can cut at most one child of each non-root node. When a second child is cut, the node itself needs to be cut from its parent and becomes the root of a new tree. The number of trees is decreased in the operation delete minimum, where trees are linked together. Here's an example Fibonacci heap that consists of 3 trees:</p> <pre><code>6 2 1 <- minimum<br /> | / | \<br /> 5 3 4 7<br /> |<br /> 8<br /> |<br /> 9<br /></code></pre> <h3 id="kruskalsalgorithm">Kruskal's Algorithm</h3> <p>Kruskal's algorithm operates from the point of view of not vertices but edges. At each step, it adds to the tree the current smallest edge unless it will produce a cycle. Obviously, the biggest challenge here is to efficiently find the cycle. Yet, the good news is that, like with the Prim's algorithm, we also have already access to an efficient solution for this problem — Union-Find. Isn't it great that we already have built a library of techniques that may be reused in creating more advanced algorithms? Actually, this is the goal of developing as an algorithms programmer — to be able to see a way to reduce the problem, at least partially, to some already known and proven solution.</p> <p>Like Prim's algorithm, Kruskal's approach also has <code>O(E logV)</code> complexity: for each vertex, it needs to find the minimum edge not forming a cycle with the already built partial MST. With Union-Find, this search requires <code>O(logE)</code>, but, as <code>E</code> is at most <code>V^2</code>, <code>logE</code> is at most <code>logV^2</code> that is equal to <code>2 logV</code>. Unlike Prim's algorithm, the partial MST built by the Kruskal's algorithm isn't necessary a tree for the already processed part of the graph.</p> <p>The implementation of the algorithm, using the existing code for Union-Find is trivial and left as an exercise to the reader.</p> <h2 id="pathfinding">Pathfinding</h2> <p>So far, we have only looked at problems with unweighted graphs. Now, we can move to weighted ones. Pathfinding in graphs is a huge topic that is crucial in many domains: maps, games, networks, etc. The goal, usually, is to find the shortest path between two nodes in a directed weighted graph. Yet, there may be variations like finding shortest paths from a selected node to all other nodes, finding the shortest path in a maze (that may be represented as a grid graph with all edges of weight 1), etc.</p> <p>There are, once again, two classic pathfinding algorithms, each one with a certain feature that makes it interesting and notable. Dijkstra's algorithm is a classic example of greedy algorithms as its alternative name suggests — shortest path first (SPF). The A* builds upon it by adding the notion of an heuristic. Dijkstra's approach is the basis of many computer network routing algorithms, such as IS-IS and OSPF, while A* and modifications are often used in games, as well as in pathfinding on the maps.</p> <h3 id="dijkstrasalgorithm">Dijkstra's Algorithm</h3> <p>The idea of Dijkstra's pathfinding is to perform a limited BFS on the graph only looking at the edges that don't lead us "away" from the target. Dijkstra's approach is very similar to the Prim's MST algorithm: it also uses a heap (Binary or Fibonacci) to store the shortest paths from the origin to each node with their weighs (lengths). At each step, it selects the minimum from the heap, expands it to the neighbor nodes, and updates the weights of the neighbors if they become smaller (the weights start from infinity).</p> <p>For our SPF implementation we'll need to use the same trick that was shown in the Union-Find implementation — extend the node structure to hold its weight and the path leading to it:</p> <pre><code>(defstruct (spf-node (:include node))<br /> (weight most-positive-infinity)<br /> (path (list)))<br /></code></pre> <p>Here is the main algorithm:</p> <pre><code>(defun spf (graph src dst)<br /> (with ((nodes (? graph 'nodes))<br /> (spf (list))<br /> ;; the following code should express initialize<br /> ;; the heap with a single node of weight 0<br /> ;; and all other nodes of weight MOST-POSITIVE-FIXNUM<br /> ;; (instead of running a O(n*log n) HEAPIFY)<br /> (weights (init-weights-heap nodes src)))<br /> (loop<br /> (with (((id weight) (heap-pop weights)))<br /> (cond ((eql id dst) (let ((dst (? nodes dst)))<br /> ;; we return 2 values: the path and its length<br /> (return (values (cons dst (? dst 'path))<br /> (? dst 'weight)))))<br /> ((= most-positive-fixnum weight) (return))) ; no path exists<br /> (dolist (edge (? nodes id 'edges))<br /> (with ((cur (? edge 'dst))<br /> (node (? nodes cur))<br /> (w (+ weight (? edge 'weight))))<br /> (when (< w (? node 'weight))<br /> (heap-decrease-key weights cur w) <br /> (:= (? node weight) w<br /> (? node path) (cons (? nodes id)<br /> (? nodes id 'path))))))))))<br /></code></pre> <h3 id="aalgorithm">A* Algorithm</h3> <p>There are many ways to improve the vanilla SPF. One of them is to move in-parallel from both sides: the source and the destination.</p> <p>A* algorithm (also called Best-First Search) improves upon the Dijkstra's method by changing how the weight of the path is estimated. Initially, it was just the distance we've already traveled in the search, which is known exactly. But we don't know for sure the length of the remaining part. However, in Euclidian and similar spaces, where the triangle inequality holds (that the direct distance between 2 points is not greater than the distance between them through any other point) it's not an unreasonable assumption that the direct path will be shorter than the circuitous ones. This premise does not always hold as there may be obstacles, but quite often it does. So, we add a second term to the weight, which is the direct distance between the current node and the destination. This simple idea underpins the A* search and allows it to perform much faster in many real-world scenarios, although its theoretical complexity is the same as for simple SPF. The exact guesstimate of the remaining distance is called the algorithm's heuristic and should be specified for each domain separately: for maps, it is the linear distance, but there are clever ways to invent similar estimates where distances can't be calculated directly.</p> <p>Overall, this algorithm is one of the simplest examples of the <strong>heuristic</strong> approach. The idea of heuristics, basically, lies in finding patterns that may significantly improve the performance of the algorithm for the common cases, although their efficiency can't be proven for the general case. Isn't it the same approach as, for example, hash-tables or splay trees that also don't guarantee the same optimal performance for each operation. The difference is that, although those techniques have possible local cases of suboptimality they provide global probabilistic guarantees. For heuristic algorithms, usually, even such estimations are not available, although they may be performed for some of them. For instance, the performance of A* algorithm will suffer if there is an "obstacle" on the direct path to the destination, and it's not possible to predict, for the general case, what will be the configuration of the graph and where the obstacles will be. Yet, even in the worst case, A* will still have at least the same speed as the basic SPF.</p> <p>The changes to the SPF algorithm needed for A* are the following:</p> <ul><li><code>init-weights-heap</code> will use the value of the heuristic instead of <code>most-positive-fixnum</code> as the initial weight. This will also require us to change the loop termination criteria from <code>(= most-positive-fixnum weight)</code> by adding some notion of visited nodes</li> <li>there will be additional term added to the weight of the node formula: <code>(+ weight (? edge 'weight) (heuristic node))</code></li></ul> <p>A good comparison of the benefits A* brings over simple SPF may be shown with this picture of pathfinding on a rectangular grid without diagonal connections, where each node is labeled with its 2d-coordinates. To find the path from node <code>(0 0)</code> to <code>(2 2)</code> (length 4) using the Dijkstra's algorithm, we'll need to visit all of the points in the grid: </p> <pre><code> 0 1 2<br />0 + .<br />1 .<br />2<br /><br /> 0 1 2<br />0 + . .<br />1 . .<br />2 .<br /><br /> 0 1 2<br />0 + . .<br />1 . . .<br />2 . .<br /><br /> 0 1 2<br />0 + > v<br />1 . . v<br />2 . . +<br /></code></pre> <p>With A*, however, we'll move straight to the point:</p> <pre><code> 0 1 2<br />0 + .<br />1 .<br />2<br /><br /> 0 1 2<br />0 + .<br />1 . .<br />2<br /><br /> 0 1 2<br />0 + .<br />1 . . .<br />2 .<br /><br /> 0 1 2<br />0 + v<br />1 . > v<br />2 . +<br /></code></pre> <p>The final path, in these pictures, is selected by the rule to always open the left neighbor first.</p> <h2 id="maximumflow">Maximum Flow</h2> <p>Weighted directed graphs are often used to represent different kinds of networks. And one of the main tasks on such networks is efficient capacity planning. The main algorithm for that is Maximum Flow calculation. It works on the so-called transport networks contain three kinds of vertices: a source, a sink, and intermediate nodes. The source has only outgoing edges, the sink has only incoming, and all the other nodes obey the balance condition: the total weights (flow) of all incoming and outgoing edges are equal. The task of determining maximum flow is to estimate the largest amount that can flow through the whole net from the source to the sink. Besides knowing the actual capacity of the network, this also allows finding the bottlenecks and edges that are not fully utilized. From such point of view, the problem is called Minimum Cut estimation.</p> <img border="0" src="https://4.bp.blogspot.com/-KYHrlhezQrY/XbF8UlBT8SI/AAAAAAAACOA/izf2WxDpp3ssHKenmtmTOwJLx5PqMzBjQCLcBGAsYHQ/s1600/max-flow-graph.jpg" /> <p>There are many approaches to solving this problem. The most direct and intuitive of them is the Ford-Fulkerson method. It is a greedy algorithm, once again, that computes the maximum flow by trying all the paths from source to sink until there is some residual capacity available. These paths are called "augmented paths" as they augment the network flow. And, to track the residual capacity, a copy of the initial weight graph called the "residual graph" is maintained. With each new path added to the total flow, its flow is subtracted from the weights of all of its edges in the residual graph. Besides — and this is the key point in the algorithm that allows it to be optimal despite its greediness — the same amount is added to the backward edges in the residual graph. The backward edges don't exist in the original graph, and they are added to the residual graph in order to let the subsequent iterations reduce the flow along some edge, but not below zero. Why this may be necessary? Each graph node has a maximum input and output capacity. It is possible to saturate the output capacity by different input edges and the optimal edge to use depends on the whole graph, so, in a single greedy step, it's not possible to determine over which edges more incoming flow should be directed. The backward edges virtually increase the output capacity by the value of the seized input capacity thus allowing the algorithm to redistribute the flow later on if necessary.</p> <p>We'll implement the FFA using the matrix graph representation. First of all, to show it in action, and also as it's easy to deal with backward edges in a matrix as they are already present, just with zero initial capacity. However, as this matrix will be sparse, in the majority of the cases, to achieve optimal efficiency, just like with most other graph algorithms, we'll need to use a better way to store the edges, for instance, an edge list. With it, we could implement the addition of backward edges directly but lazily during the processing of each augmented path.</p> <pre><code>(defstuct mf-edge<br /> beg end capacity)<br /><br />(defun max-flow (g)<br /> (let ((rg (copy-array g)) ; residual graph<br /> (rez 0))<br /> (loop :for path := (aug-path rg) :while path :do<br /> (let ((flow most-positive-fixnum))<br /> ;; the flow along the path is the residual capacity<br /> ;; of the least wide edge<br /> (dolist (edge path)<br /> (let ((cap (? edge 'capacity)))<br /> (when (< (abs cap) flow)<br /> (:= flow (abs cap)))))<br /> (dolist (edge path)<br /> (with (((beg end) ? edge))<br /> (:- (aref rg beg end) flow)<br /> (:+ (aref rg end beg) flow)))<br /> (:+ rez flow)))<br /> rez))<br /><br />(defun aug-path (g)<br /> (with ((sink (1- (array-dimension g 0)))<br /> (visited (make-array (1+ sink) :initial-element nil)))<br /> (labels ((dfs (g i)<br /> (if (zerop (aref g i sink))<br /> (dotimes (j sink)<br /> (unless (or (zerop (aref g i j))<br /> (? visited j))<br /> (when-it (dfs g j)<br /> (:= (? visited j) t)<br /> (return (cons (make-mf-edge :beg i :end j<br /> :capacity (aref g i j))<br /> it)))))<br /> (list (make-mf-edge :beg i :end sink<br /> :capacity (aref g i sink))))))<br /> (dfs g 0))))<br /><br />CL-USER> (max-flow #2A((0 4 4 0 0 0)<br /> (0 0 0 4 2 0)<br /> (0 0 0 1 2 0)<br /> (0 0 0 0 0 3)<br /> (0 0 0 0 0 5))))<br />7<br /></code></pre> <p>So, as you can see from the code, to find an augmented path, we need to perform DFS on the graph from the source, sequentially examining the edges with some residual capacity to find a path to the sink.</p> <p>A peculiarity of this algorithm is that there is no certainty that we'll eventually reach the state when there will be no augmented paths left. The FFA works correctly for integer and rational weights, but when they are irrational it is not guaranteed to terminate. When the capacities are integers, the runtime of Ford-Fulkerson is bounded by <code>O(E f)</code> where <code>f</code> is the maximum flow in the graph. This is because each augmented path can be found in <code>O(E)</code> time and it increases the flow by an integer amount of at least 1. A variation of the Ford-Fulkerson algorithm with guaranteed termination and a runtime independent of the maximum flow value is the Edmonds-Karp algorithm, which runs in <code>O(V E^2)</code>.</p> <h2 id="graphsinactionpagerank">Graphs in Action: PageRank</h2> <p>Another important set of problems from the field of network analysis is determining "centers of influence", densely and sparsely populated parts, and "cliques". PageRank is the well-known algorithm for ranking the nodes in terms of influence (i.e. the number and weight of incoming connections they have), which was the secret sauce behind Google's initial success as a search engine. It will be the last of the graph algorithms we'll discuss in this chapter, so many more will remain untouched. We'll be returning to some of them in the following chapters, and you'll be seeing them in many problems once you develop an eye for spotting the graphs hidden in many domains.</p> <p>PageRank algorithm outputs a probability distribution of the likelihood that a person randomly clicking on links will arrive at any particular page. This distribution ranks the relative importance of all pages. The probability is expressed as a numeric value between 0 and 1, but Google used to multiply it by 10 and round to the greater integer, so PR of 10 corresponded to the probability of 0.9 and more and PR=1 — to the interval from 0 to 0.1. In the context of Pagerank, all web pages are the nodes in the so-called webgraph, and the links between them are the edges, originally, weighted equally.</p> <p>PageRank is an iterative algorithm that may be considered an instance of the very popular, in unsupervised optimization and machine learning, <strong>Expectation Maximization</strong> (EM) approach. The general idea of EM is to randomly initialize the quantities that we want to estimate, and then iteratively recalculate each quantity, using the information from the neighbors, to "move" it closer to the value that ensures optimality of the target function. Epochs (an iteration that spans the whole data set using each node at most once) of such recalculation should continue either until the whole epoch doesn't produce a significant change of the loss function we're optimizing, i.e. we have reached the stationary point, or a satisfactory number of iterations was performed. Sometimes a stationary point either can't be reached or will take too long to reach, but, according to Pareto's principle, 20% of effort might have moved us 80% to the goal.</p> <p>In each epoch, we recalculate the PageRank of all nodes by transferring weights from a node equally to all of its neighbors. The neighbors with more inbound connections will thus receive more weight. However, the PageRank concept adds a condition that an imaginary surfer who is randomly clicking on links will eventually stop clicking. The probability that the transfer will continue is called a damping factor <code>d</code>. Various studies have tested different damping factors, but it is generally assumed that the damping factor for the webgraph will be set around 0.85. The damping factor is subtracted from 1 (and in some variations of the algorithm, the result is divided by the number of documents in the collection) and this term is then added to the product of the damping factor and the sum of the incoming PageRank scores. The damping factor is subtracted from 1 (and in some variations of the algorithm, the result is divided by the number of documents (N) in the collection) and this term is then added to the product of the damping factor and the sum of the incoming PageRank scores. So the PageRank of a page is mostly derived from the PageRanks of other pages. The damping factor adjusts the derived value downward.</p> <h3 id="implementation">Implementation</h3> <p>Actually, PageRank can be computed both iteratively and algebraically. In algebraic form, each PageRank iteration may be expressed simply as:</p> <pre><code>(:= pr (+ (* d (mat* g pr))<br /> (/ (- 1 d) n)))<br /></code></pre> <p>where <code>g</code> is the graph incidence matrix and <code>pr</code> is the vector of PageRank for each node.</p> <p>However, the definitive property of PageRank is that it is estimated for huge graphs. I.e. directly representing them as matrices isn't possible as well as performing the matrix operations on them. The iterative algorithm allows more control as well as distributing of the computation, so it is usually preferred, in practice, not only for Pagerank but also for most other optimization techniques. Sp PageRank should be viewed primarily as a distributed algorithm. The need to implement it on a large cluster triggered the development by Google of the influential MapReduce distributed computation framework.</p> <p>Here is a simplified PageRank implementation of the iterative method:</p> <pre><code>(defun pagerank (g &key (d 0.85) (repeat 100))<br /> (with ((n (tally (nodes g)))<br /> (pr (make-arrray n :initial-element (/ 1 n)))<br /> (loop :repeat repeat :do<br /> (let ((pr2 (map 'vector (lambda (x) (- 1 (/ d n)))<br /> pr)))<br /> (dokv (i node nodes)<br /> (let ((p (? pr i))<br /> (m (tally (? node 'children)))<br /> (dokv (j child (? node 'children))<br /> (:+ (? pr2 j) (* d (/ p m))))))<br /> (:= pr pr2))<br /> pr))<br /></code></pre> <p>We use the same graph representation as previously and perform the update "backwards": not by gathering all incoming edges, which will require us to add another layer of data that is both not necessary and hard to maintain, but transferring the PR value over outgoing edges one by one. Such an approach also makes the computation trivially to distribute as we can split the whole graph into arbitrary set of nodes and the computation for each set can be performed in parallel: we'll just need to maintain a local copy of the <code>pr2</code> vector and merge it at the end of each iteration by simple summation. This method naturally fits the map-reduce framework: the <code>map</code> step is the inner node loop, while the <code>reduce</code> step is merging of the <code>pr2</code> vectors.</p> <h2 id="takeaways">Take-aways</h2> <ol><li>The more we progress into advanced topics of this book, the more apparent will be the tendency to reuse the approaches, tools, and technologies we have developed previously. Graph algorithms are good demonstrations of new features and qualities that can be obtained by a smart combination and reuse of existing data structures.</li><li>Many graph algorithms are greedy. This means that they use the locally optimal solution trying to arrive at a global one. This is conditioned by the structure — or rather lack of structure — of graphs that don't have a specific hierarchy to guide the optimal solution. The greediness, however, shouldn't mean suboptimality. In many greedy algorithms, like FFA, there is a way to play back the wrong solution. Others provide a way to trade off execution speed and optimality. A good example of the latter approach is Beam search that we'll discuss in the next chapters.</li><li>In A*, we had a first glimpse of heuristic algorithms — an area that may be quite appealing to many programmers who are used to solving the problem primarily optimizing for its main scenarios. This approach may lack some mathematical rigor, but it also has its place and we'll see other heuristic algorithms in the following chapters that are, like A*, the best practical solution in their domains: for instance, the Monte Carlo Tree Search (MCTS).</li><li>Another thing that becomes more apparent in the progress of this book is how small the percentage of the domain we can cover in detail in each chapter. This is true for graphs: we have just scratched the surface and outlined the main approaches to handling them. We'll see more of graph-related stuff in the following chapters, as well. Graph algorithms may be quite useful in a great variety of areas that not necessarily have a direct formulation as graph problems (like maps or networks do) and so developing an intuition to recognize the hidden graph structure may help the programmer reuse the existing elegant techniques instead of having to deal with own cumbersome ad-hoc solutions.</li></ol> <hr size="1" />Thu, 24 Oct 2019 13:09:00 GMTLispers.de: Berlin Lispers Meetup, Monday, 28th October 2019https://www.lispers.de/#2019-10-28-Berlin
https://www.lispers.de/#2019-10-28-Berlin
<p class="content">We meet again on Monday 8pm, 28th October. Our host this time is
James Anderson (www.dydra.com).</p><p class="content">Berlin Lispers is about all flavors of Lisp including Emacs Lisp, Scheme, and Clojure.</p><p class="content">This time we talk about the Advent of Code and look at examples in Common Lisp.</p><p class="content">[1] https://twitter.com/ericwastl/status/1178596028662112256</p><p class="content">[2] https://adventofcode.com/</p><p class="content">[3] https://old.reddit.com/r/adventofcode/</p><p class="content">We meet in the Taut-Haus at Engeldamm 70 in Berlin-Mitte, the bell is "James Anderson".
It is located in 10min walking distance from U Moritzplatz or U Kottbusser Tor or Ostbahnhof.
In case of questions call Christian +49 1578 70 51 61 4.</p>Thu, 24 Oct 2019 09:30:00 GMTLispers.de: Berlin Lispers - Talk Announcement - Thursday, 24th October 2019https://www.lispers.de/#2019-10-24-Berlin
https://www.lispers.de/#2019-10-24-Berlin
<p class="content">Georg Kinnemann will give a talk about LISP and AI with the title "Die Entwicklung eines Spezial-Computers für Künstliche Intelligenz in der DDR" at Deutsche Technikmuseum Berlin.</p><p class="content">5.30pm, 24th October</p><p class="content">Deutsches Technikmuseum, Trebbiner Straße 9, Vortragssaal, 4. OG</p><p class="content">[1] https://sdtb.de/technikmuseum/veranstaltungen/ein-spezial-computer-fuer-kuenstliche-intelligenz-in-der-ddr/</p><p class="content">[2] https://lispers.de/docs/ki-spezialcomputer-dtb-20191024.txt</p>Mon, 21 Oct 2019 15:10:00 GMTQuicklisp news: October 2019 Quicklisp dist update now availablehttp://blog.quicklisp.org/2019/10/october-2019-quicklisp-dist-update-now.html
http://blog.quicklisp.org/2019/10/october-2019-quicklisp-dist-update-now.html
<b>New projects</b>:<br /><ul><li><a href="https://github.com/3b/3bz/">3bz</a> — deflate decompressor — MIT</li><li><a href="https://github.com/mrwhythat/bp/">bp</a> — Bitcoin Protocol components in Common Lisp — MIT</li><li><a href="https://gitlab.com/a.aguilar/cardiogram">cardiogram</a> — Simple test framework — MIT</li><li><a href="https://www.hexstreamsoft.com/libraries/cesdi/">cesdi</a> — Provides a compute-effective-slot-definition-initargs generic function that allows for more ergonomic initialization of effective slot definition objects. — Unlicense</li><li><a href="https://github.com/sheepduke/chameleon/">chameleon</a> — Configuration management facilities for Common Lisp with multiple profile support. — MIT</li><li><a href="https://github.com/neil-lindquist/ci-utils/">ci-utils</a> — A set of tools for using CI platforms — MIT</li><li><a href="https://github.com/gos-k/cl-clsparse/">cl-clsparse</a> — Common Lisp bindings for clSPARSE — Apache License, Version 2.0</li><li><a href="file://private/tmp/verisimilitudes.net">cl-ecma-48</a> — This package exports a macro for defining ECMA-48 control functions and the 162 functions defined by this. — AGPLv3</li><li><a href="https://github.com/noffle/cl-flat-tree/">cl-flat-tree</a> — A flat-tree implementation in Common Lisp. — MIT</li><li><a href="https://github.com/jonatack/cl-kraken">cl-kraken</a> — A Common Lisp API client for the Kraken exchange — MIT</li><li><a href="https://gitlab.com/Harag/cl-naive-store">cl-naive-store</a> — This is a naive, persisted, in memory (lazy loading) data store for Common Lisp. — MIT</li><li><a href="https://github.com/ruricolist/cl-shlex/">cl-shlex</a> — Lexical analyzer for simple shell-like syntax. — MIT</li><li><a href="https://github.com/GrammaTech/cl-smt-lib/">cl-smt-lib</a> — SMT object supporting SMT-LIB communication over input and output streams — BSD-3-Clause</li><li><a href="https://github.com/remexre/cl-wadler-pprint/">cl-wadler-pprint</a> — An implementation of A Prettier Printer in Common Lisp. — Apache-2.0/MIT</li><li><a href="https://github.com/Shinmera/classowary">classowary</a> — An implementation of the Cassowary linear constraint solver toolkit — zlib</li><li><a href="https://github.com/moderninterpreters/clsql-local-time/">clsql-local-time</a> — Allows the use of local-time:timestamp objects in CLSQL models and queries — MIT license</li><li><a href="https://github.com/defaultxr/datamuse/">datamuse</a> — Common Lisp library for accessing the Datamuse word-finding API — MIT</li><li><a href="https://github.com/ruricolist/date-calc/">date-calc</a> — Package for simple date calculation — GPL or Artistic</li><li><a href="https://github.com/Shinmera/font-discovery">font-discovery</a> — Find system font files matching a font spec. — zlib</li><li><a href="https://gitlab.com/ralt/horse-html">horse-html</a> — Parenscript/HTML done better — MIT</li><li><a href="https://github.com/moderninterpreters/hunchentoot-multi-acceptor/">hunchentoot-multi-acceptor</a> — Multiple domain support under single hunchentoot acceptor — Apache License, Version 2.0</li><li><a href="https://github.com/codr7/lila/">lila</a> — a cleaner language based on Common Lisp — MIT</li><li><a href="https://neil-lindquist.github.io/linear-programming/">linear-programming</a> — A library for solving linear programming problems — MIT</li><li><a href="https://github.com/fukamachi/lsx/">lsx</a> — Embeddable HTML templating engine with JSX-like syntax — BSD 2-Clause</li><li><a href="https://github.com/moderninterpreters/markup/">markup</a> — markup provides a reader-macro to read HTML/XML tags inside of Common Lisp code — Apache License, Version 2.0</li><li><a href="https://github.com/Symbolics/num-utils/">num-utils</a> — Numerical utilities for Common Lisp — Boost Software License - Version 1.0</li><li><a href="https://notabug.org/cage/orizuru-orm/">orizuru-orm</a> — An ORM for Common Lisp and PostgreSQL. — GPLv3</li><li><a href="https://github.com/BnMcGn/paren6/">paren6</a> — Paren6 is a set of ES6 macros for Parenscript — Apache License, version 2.0</li><li><a href="https://www.michaelfiano.com/projects/pngload-fast">pngload-fast</a> — A reader for the PNG image format. — MIT</li><li><a href="https://github.com/mrcdr/polisher">polisher</a> — Infix notation to S-expression translator — MIT</li><li><a href="http://inference.sg/projects/select/">select</a> — DSL for array slices. — Boost</li><li><a href="https://github.com/glv2/simple-parallel-tasks/">simple-parallel-tasks</a> — Evaluate forms in parallel — GPL-3</li><li><a href="https://www.michaelfiano.com/projects/stripe">stripe</a> — A client for the Stripe payment API. — MIT</li><li><a href="https://shinmera.github.io/trivial-extensible-sequences/">trivial-extensible-sequences</a> — Portability library for the extensible sequences protocol. — zlib</li><li><a href="https://github.com/phoe/trivial-package-local-nicknames/">trivial-package-local-nicknames</a> — Portability library for package-local nicknames — Public domain</li><li><a href="https://github.com/Shinmera/uax-14">uax-14</a> — Implementation of the Unicode Standards Annex #14's line breaking algorithm — zlib</li><li><a href="https://github.com/Shinmera/uax-9">uax-9</a> — Implementation of the Unicode Standards Annex #9's bidirectional text algorithm — zlib</li><li><a href="https://www.hexstreamsoft.com/libraries/with-output-to-stream/">with-output-to-stream</a> — Provides a simple way of directing output to a stream according to the concise and intuitive semantics of FORMAT's stream argument. — Public Domain</li><li><a href="https://github.com/yitzchak/ziz/">ziz</a> — An ad hoc Quicklisp distribution. — MIT</li></ul><b>Updated projects:</b> <a href="http://quickdocs.org/3d-matrices/">3d-matrices</a>, <a href="http://quickdocs.org/also-alsa/">also-alsa</a>, <a href="http://quickdocs.org/anaphora/">anaphora</a>, <a href="http://quickdocs.org/antik/">antik</a>, <a href="http://quickdocs.org/april/">april</a>, <a href="http://quickdocs.org/architecture.service-provider/">architecture.service-provider</a>, <a href="http://quickdocs.org/asdf-encodings/">asdf-encodings</a>, <a href="http://quickdocs.org/asteroids/">asteroids</a>, <a href="http://quickdocs.org/atomics/">atomics</a>, <a href="http://quickdocs.org/bike/">bike</a>, <a href="http://quickdocs.org/binary-io/">binary-io</a>, <a href="http://quickdocs.org/binfix/">binfix</a>, <a href="http://quickdocs.org/bknr-datastore/">bknr-datastore</a>, <a href="http://quickdocs.org/black-tie/">black-tie</a>, <a href="http://quickdocs.org/bodge-chipmunk/">bodge-chipmunk</a>, <a href="http://quickdocs.org/bodge-glfw/">bodge-glfw</a>, <a href="http://quickdocs.org/bodge-nanovg/">bodge-nanovg</a>, <a href="http://quickdocs.org/bodge-nuklear/">bodge-nuklear</a>, <a href="http://quickdocs.org/bodge-ode/">bodge-ode</a>, <a href="http://quickdocs.org/bodge-openal/">bodge-openal</a>, <a href="http://quickdocs.org/bodge-sndfile/">bodge-sndfile</a>, <a href="http://quickdocs.org/caveman/">caveman</a>, <a href="http://quickdocs.org/cepl/">cepl</a>, <a href="http://quickdocs.org/cl+ssl/">cl+ssl</a>, <a href="http://quickdocs.org/cl-algebraic-data-type/">cl-algebraic-data-type</a>, <a href="http://quickdocs.org/cl-amqp/">cl-amqp</a>, <a href="http://quickdocs.org/cl-change-case/">cl-change-case</a>, <a href="http://quickdocs.org/cl-collider/">cl-collider</a>, <a href="http://quickdocs.org/cl-cookie/">cl-cookie</a>, <a href="http://quickdocs.org/cl-coveralls/">cl-coveralls</a>, <a href="http://quickdocs.org/cl-cuda/">cl-cuda</a>, <a href="http://quickdocs.org/cl-dbi/">cl-dbi</a>, <a href="http://quickdocs.org/cl-digikar-utilities/">cl-digikar-utilities</a>, <a href="http://quickdocs.org/cl-fad/">cl-fad</a>, <a href="http://quickdocs.org/cl-fond/">cl-fond</a>, <a href="http://quickdocs.org/cl-freetype2/">cl-freetype2</a>, <a href="http://quickdocs.org/cl-geocode/">cl-geocode</a>, <a href="http://quickdocs.org/cl-hamcrest/">cl-hamcrest</a>, <a href="http://quickdocs.org/cl-ipfs-api2/">cl-ipfs-api2</a>, <a href="http://quickdocs.org/cl-kanren/">cl-kanren</a>, <a href="http://quickdocs.org/cl-ledger/">cl-ledger</a>, <a href="http://quickdocs.org/cl-lexer/">cl-lexer</a>, <a href="http://quickdocs.org/cl-lzlib/">cl-lzlib</a>, <a href="http://quickdocs.org/cl-mango/">cl-mango</a>, <a href="http://quickdocs.org/cl-markless/">cl-markless</a>, <a href="http://quickdocs.org/cl-mssql/">cl-mssql</a>, <a href="http://quickdocs.org/cl-openstack-client/">cl-openstack-client</a>, <a href="http://quickdocs.org/cl-patterns/">cl-patterns</a>, <a href="http://quickdocs.org/cl-pdf/">cl-pdf</a>, <a href="http://quickdocs.org/cl-permutation/">cl-permutation</a>, <a href="http://quickdocs.org/cl-python/">cl-python</a>, <a href="http://quickdocs.org/cl-qrencode/">cl-qrencode</a>, <a href="http://quickdocs.org/cl-rdkafka/">cl-rdkafka</a>, <a href="http://quickdocs.org/cl-readline/">cl-readline</a>, <a href="http://quickdocs.org/cl-sat/">cl-sat</a>, <a href="http://quickdocs.org/cl-sat.glucose/">cl-sat.glucose</a>, <a href="http://quickdocs.org/cl-sat.minisat/">cl-sat.minisat</a>, <a href="http://quickdocs.org/cl-sdl2/">cl-sdl2</a>, <a href="http://quickdocs.org/cl-sqlite/">cl-sqlite</a>, <a href="http://quickdocs.org/cl-str/">cl-str</a>, <a href="http://quickdocs.org/cl-tiled/">cl-tiled</a>, <a href="http://quickdocs.org/cl-yesql/">cl-yesql</a>, <a href="http://quickdocs.org/clack/">clack</a>, <a href="http://quickdocs.org/clack-errors/">clack-errors</a>, <a href="http://quickdocs.org/closer-mop/">closer-mop</a>, <a href="http://quickdocs.org/clx/">clx</a>, <a href="http://quickdocs.org/coleslaw/">coleslaw</a>, <a href="http://quickdocs.org/command-line-arguments/">command-line-arguments</a>, <a href="http://quickdocs.org/common-lisp-jupyter/">common-lisp-jupyter</a>, <a href="http://quickdocs.org/concrete-syntax-tree/">concrete-syntax-tree</a>, <a href="http://quickdocs.org/croatoan/">croatoan</a>, <a href="http://quickdocs.org/data-lens/">data-lens</a>, <a href="http://quickdocs.org/datum-comments/">datum-comments</a>, <a href="http://quickdocs.org/definitions/">definitions</a>, <a href="http://quickdocs.org/deploy/">deploy</a>, <a href="http://quickdocs.org/dexador/">dexador</a>, <a href="http://quickdocs.org/drakma/">drakma</a>, <a href="http://quickdocs.org/dufy/">dufy</a>, <a href="http://quickdocs.org/easy-routes/">easy-routes</a>, <a href="http://quickdocs.org/eclector/">eclector</a>, <a href="http://quickdocs.org/eco/">eco</a>, <a href="http://quickdocs.org/envy/">envy</a>, <a href="http://quickdocs.org/erudite/">erudite</a>, <a href="http://quickdocs.org/esrap/">esrap</a>, <a href="http://quickdocs.org/esrap-peg/">esrap-peg</a>, <a href="http://quickdocs.org/fare-scripts/">fare-scripts</a>, <a href="http://quickdocs.org/fast-http/">fast-http</a>, <a href="http://quickdocs.org/fast-websocket/">fast-websocket</a>, <a href="http://quickdocs.org/femlisp/">femlisp</a>, <a href="http://quickdocs.org/fiasco/">fiasco</a>, <a href="http://quickdocs.org/float-features/">float-features</a>, <a href="http://quickdocs.org/flow/">flow</a>, <a href="http://quickdocs.org/folio2/">folio2</a>, <a href="http://quickdocs.org/fxml/">fxml</a>, <a href="http://quickdocs.org/gendl/">gendl</a>, <a href="http://quickdocs.org/glsl-spec/">glsl-spec</a>, <a href="http://quickdocs.org/glsl-toolkit/">glsl-toolkit</a>, <a href="http://quickdocs.org/golden-utils/">golden-utils</a>, <a href="http://quickdocs.org/graph/">graph</a>, <a href="http://quickdocs.org/helambdap/">helambdap</a>, <a href="http://quickdocs.org/hermetic/">hermetic</a>, <a href="http://quickdocs.org/http-body/">http-body</a>, <a href="http://quickdocs.org/ironclad/">ironclad</a>, <a href="http://quickdocs.org/jsonrpc/">jsonrpc</a>, <a href="http://quickdocs.org/jsown/">jsown</a>, <a href="http://quickdocs.org/kenzo/">kenzo</a>, <a href="http://quickdocs.org/lack/">lack</a>, <a href="http://quickdocs.org/lastfm/">lastfm</a>, <a href="http://quickdocs.org/lisp-binary/">lisp-binary</a>, <a href="http://quickdocs.org/literate-lisp/">literate-lisp</a>, <a href="http://quickdocs.org/log4cl/">log4cl</a>, <a href="http://quickdocs.org/lucerne/">lucerne</a>, <a href="http://quickdocs.org/magicl/">magicl</a>, <a href="http://quickdocs.org/maiden/">maiden</a>, <a href="http://quickdocs.org/matlisp/">matlisp</a>, <a href="http://quickdocs.org/mcclim/">mcclim</a>, <a href="http://quickdocs.org/mito/">mito</a>, <a href="http://quickdocs.org/nineveh/">nineveh</a>, <a href="http://quickdocs.org/ningle/">ningle</a>, <a href="http://quickdocs.org/nodgui/">nodgui</a>, <a href="http://quickdocs.org/origin/">origin</a>, <a href="http://quickdocs.org/overlord/">overlord</a>, <a href="http://quickdocs.org/parachute/">parachute</a>, <a href="http://quickdocs.org/parse/">parse</a>, <a href="http://quickdocs.org/parser.common-rules/">parser.common-rules</a>, <a href="http://quickdocs.org/patchwork/">patchwork</a>, <a href="http://quickdocs.org/petalisp/">petalisp</a>, <a href="http://quickdocs.org/piggyback-parameters/">piggyback-parameters</a>, <a href="http://quickdocs.org/pjlink/">pjlink</a>, <a href="http://quickdocs.org/pngload/">pngload</a>, <a href="http://quickdocs.org/portableaserve/">portableaserve</a>, <a href="http://quickdocs.org/postmodern/">postmodern</a>, <a href="http://quickdocs.org/proc-parse/">proc-parse</a>, <a href="http://quickdocs.org/prometheus.cl/">prometheus.cl</a>, <a href="http://quickdocs.org/py4cl/">py4cl</a>, <a href="http://quickdocs.org/qlot/">qlot</a>, <a href="http://quickdocs.org/quilc/">quilc</a>, <a href="http://quickdocs.org/quri/">quri</a>, <a href="http://quickdocs.org/qvm/">qvm</a>, <a href="http://quickdocs.org/random/">random</a>, <a href="http://quickdocs.org/ratify/">ratify</a>, <a href="http://quickdocs.org/re/">re</a>, <a href="http://quickdocs.org/replic/">replic</a>, <a href="http://quickdocs.org/restas/">restas</a>, <a href="http://quickdocs.org/rove/">rove</a>, <a href="http://quickdocs.org/rpcq/">rpcq</a>, <a href="http://quickdocs.org/rtg-math/">rtg-math</a>, <a href="http://quickdocs.org/rutils/">rutils</a>, <a href="http://quickdocs.org/sc-extensions/">sc-extensions</a>, <a href="http://quickdocs.org/scalpl/">scalpl</a>, <a href="http://quickdocs.org/sel/">sel</a>, <a href="http://quickdocs.org/serapeum/">serapeum</a>, <a href="http://quickdocs.org/shadow/">shadow</a>, <a href="http://quickdocs.org/should-test/">should-test</a>, <a href="http://quickdocs.org/simplified-types/">simplified-types</a>, <a href="http://quickdocs.org/sly/">sly</a>, <a href="http://quickdocs.org/spinneret/">spinneret</a>, <a href="http://quickdocs.org/staple/">staple</a>, <a href="http://quickdocs.org/stumpwm/">stumpwm</a>, <a href="http://quickdocs.org/swank-client/">swank-client</a>, <a href="http://quickdocs.org/trivia/">trivia</a>, <a href="http://quickdocs.org/trivial-continuation/">trivial-continuation</a>, <a href="http://quickdocs.org/trivial-hashtable-serialize/">trivial-hashtable-serialize</a>, <a href="http://quickdocs.org/trivial-indent/">trivial-indent</a>, <a href="http://quickdocs.org/trivial-json-codec/">trivial-json-codec</a>, <a href="http://quickdocs.org/trivial-left-pad/">trivial-left-pad</a>, <a href="http://quickdocs.org/trivial-monitored-thread/">trivial-monitored-thread</a>, <a href="http://quickdocs.org/trivial-object-lock/">trivial-object-lock</a>, <a href="http://quickdocs.org/trivial-pooled-database/">trivial-pooled-database</a>, <a href="http://quickdocs.org/trivial-timer/">trivial-timer</a>, <a href="http://quickdocs.org/trivial-utilities/">trivial-utilities</a>, <a href="http://quickdocs.org/trivial-variable-bindings/">trivial-variable-bindings</a>, <a href="http://quickdocs.org/type-i/">type-i</a>, <a href="http://quickdocs.org/umbra/">umbra</a>, <a href="http://quickdocs.org/uri-template/">uri-template</a>, <a href="http://quickdocs.org/utilities.print-items/">utilities.print-items</a>, <a href="http://quickdocs.org/varjo/">varjo</a>, <a href="http://quickdocs.org/verbose/">verbose</a>, <a href="http://quickdocs.org/vernacular/">vernacular</a>, <a href="http://quickdocs.org/woo/">woo</a>, <a href="http://quickdocs.org/zs3/">zs3</a>.<br /><br />To get this update, use (ql:update-dist "quicklisp").<br /><br />If you get a "badly sized local archive" error during the update, you can also safely use the DELETE-AND-RETRY restart to proceed. This error was introduced by a metadata problem on my end. Sorry about that!Mon, 14 Oct 2019 13:14:00 GMTDidier Verna: TFM 1.0 "Artificial Uncial" is released.https://www.didierverna.net/blog/index.php?post/2019/10/09/TFM-1.0-Artificial-Uncial-is-released.
https://www.didierverna.net/blog/index.php?post/2019/10/09/TFM-1.0-Artificial-Uncial-is-released.
<p>I'm happy to announce the first stable version of TFM, a TeX Font Metrics parser for Common Lisp. TFM is the standard font description format used by TeX. The TFM library parses and decodes TFM files into an abstract data structure, providing easy access to the corresponding font information. Get it <a href="https://github.com/didierverna/tfm" hreflang="en">here</a>.</p>Wed, 09 Oct 2019 00:00:00 GMTLispers.de: Lisp-Meetup in Hamburg on Monday, 7th October 2019https://www.lispers.de/#2019-10-07-Hamburg
https://www.lispers.de/#2019-10-07-Hamburg
<p class="content">We meet at Ristorante Opera, Dammtorstraße 7, Hamburg, starting around 19:00 CEST on 7th October 2019.</p><p class="content">This is an informal gathering of Lispers of all experience levels.</p>Mon, 07 Oct 2019 00:00:00 GMT