My goals while writing the program were manifold (pun intended):

1. First and foremost, I wanted to understand the simulation techniques used by a research group that I collaborate with. Among these are parallel tempering (a.k.a. replica exchange) Monte Carlo, WHAM, etc.
2. I was also looking forward to learning OpenMP and the GNU Scientific Library for quite some time, so this gave me the perfect opportunity to do so.
3. Many projects have been migrating from GNU autotools to CMake. I was curious about it and wanted to become acquainted with CMake too.

The code can still be improved upon, of course. But besides cleanups or feature additions, and considering that my new toycomputer at work has two NVIDIA Tesla M2050s, I think the next step is to develop GPU capabilities.

Oh, I almost forgot that its Git repository is cloned at Github.

I was told it was trivial to roll your own doctest suite in Common Lisp. I have done that and it is easy indeed but I have included the code in incf-cl for those who would like to use it right away.

Here’s an example:

  (defpackage :test
    (:use :common-lisp :incf-cl)
    (:export :factorial))

  (in-package :test)

  (defun factorial (n &optional (acc 1))
    "Returns the factorial of N, where N is an integer >= 0.

    Examples:

    TEST> (assemble (factorial n) (<- n (range 1 5)))
    (1 2 6 24 120)

    TEST> (factorial 450/15)
    265252859812191058636308480000000

    TEST> (signals-p arithmetic-error (factorial -1))
    T

    TEST> (signals-p type-error (factorial 30.1))
    T

    TEST> (factorial 0)
    1"
    (declare (type integer n))

    (cond
      ((minusp n) (error 'arithmetic-error))
      ((/= n (floor n)) (error 'type-error)))

    (if (= n 0)
        acc
        (factorial (1- n) (* n acc))))

CL-USER> (doctest :test)
.....T

I wanted to write this myself for a long time but what prevented me from doing so was the fact that I had come up with a trivial shell/awk script that achieved almost the same goal. Since that little program was useful for someone other than me, I thought I’d polish it slightly and post it here.

This tool’s original intent was to print a call graph from a given program. It works by taking control of GDB and automatically setting breakpoints at each function call. Of course, the executable must include debugging symbols (that is, it must have been compiled with gcc’s -g option). Here’s some sample output (the format is: caller callee arguments):

xmltree_parse xmltree_itor_next (self=0x80571e8)
xmltree_itor_next xmlnode_stack_push (stack=0x80571f0, n=0x8056780)
xmltree_parse h_requires (n=0x8056808, u=0xbff9d504)
h_requires xmlnode_get_attr (self=0x8056808, name=0x80520ea "plugin")
h_requires probe_get_name (self=0x8056af0)
h_requires htab_lookup (self=0x8058100, key=0x8056868, len=3, create=0, value=0x0)


You can use the included cg2dot.awk script to produce files suitable for processing with graphviz.

Having list comprehensions in Lisp was something I was missing from Python and Haskell. So I tried to find something similar and discovered that the LOOP facility can be used as a means of achieving this goal but this, although nice, didn’t feel natural enough. In the end, I read the paper Simple and Efficient Compilation of List Comprehension in Common Lisp by Mario Latendresse which appeared at ILC 2007 and have decided to adopt that implementation for translating list comprehensions into loops.

For example, the set  \(\left\{ (x, y) \in \{0, 1, 2\}^2 \, | \, x +y = 2 \right\}\) can be expressed as

(lc (cons x y) (<- x '(0 1 2)) (<- y '(0 1 2)) (= (+ x y) 2))  ==>
((0 . 2) (1 . 1) (2 . 0))

Another example:

(lc (sin x) (<- x (range 0 .1 (/ pi 2)))) ==>
(0.0 0.09983342 0.19866933 0.29552022 0.38941833 0.47942555 0.5646425 0.6442177
 0.71735615 0.783327 0.8414711 0.8912074 0.93203914 0.96355826 0.9854498
 0.997495)

The macro I’m using is lc:

(defmacro lc (collection-form &rest quantifiers)
  "Assembles a multiset containing the results of evaluating
COLLECTION-FORM and subject to QUANTIFIERS."
  (labels ((translate (collection-form qs)
             (if (null qs)
                 `(collect ,collection-form)
                 (translate-generator-or-filter collection-form qs)))
           (translate-generator-or-filter (collection-form qs)
             (let ((q (first qs))
                   (qr (rest qs)))
               (if (eq (first q) '<-)
                   (translate-generator collection-form (second q) (third q) qr)
                   (translate-filter collection-form q qr))))
           (translate-generator (collection-form variable collection qs)
             `(nconc (loop for ,variable in ,collection
                          ,@(translate collection-form qs))))
           (translate-filter (collection-form filter-form qs)
             `(when ,filter-form ,@(translate collection-form qs))))
    (when quantifiers
      `(loop repeat 1 ,@(translate collection-form quantifiers)))))

and the helper function range is:

(defun range (a b &optional c)
  "Builds a range of numbers as Matlab would do"
  (flet ((|:| (start step stop)
           (assert (and (<= start stop) (> step 0)))
           (loop for x from start to stop by step collect x)))
    (if c
        (|:| a b c)
        (|:| a 1 b))))

A possible enhancement would be to translate to series instead
of loop in order to have lazy list comprehensions.

This code (and more) can be found in the (incf cl) utilities.

There are many improvements waiting in the pipeline but the basic
functionality is there.

You can read more about cl-buchberger here.

This library used an undocumented (at the time) glibc function called backtrace(3) which would return memory locations but not function names. Today, browsing old source code, I reviewed the library and was glad to see that backtrace(3) is currently not only documented but it also offers the same features my library did, so I won’t be updating Libbtrace anymore.