Scott Turner has written a guide to using Quicklisp with an authenticated proxy. Thanks, Scott!

09 Mar 2014 10:07pm GMT

I just spent the evening filling two boxes with books I'll bring from Québec to my new apartment in New York. To my surprise and delight, that's less than a third of my collection (plus newer ones I have yet to make my mind about). Perhaps this list of books that survived the cull can guide others in their acquisitions. If you're around NYC, I'd also be very happy to share my stash!

EDIT: I was asked for feedback on some of these books, so I added some inline.

Fundamentals

Brassard and Bratley, Fundamentals of Algorithmics is my go-to reference book for basic algorithmic stuff. I love the presentation, the authors are careful with Landau notation, and they specify in what circumstances hand-waving tricks apply. The quality of Brassard's lectures is probably a factor as well: the book reminds me of one of the best courses in Université de Montréal's undergraduate curriculum.

CLRS for baseline implementations of classic data structures and algorithms.

Knuth 1-4A for its attention to minutiae. Also very useful as a reference to point to: if something is so old or well known that I can't think of a canonical reference, it's probably in Knuth.

Sedgewick, Algorithms (First edition) has an interesting section on geometric algorithms. I also like the way many older data structure and algorithm books clearly take low-level coding consideration into account while discussing asymptotics. I find nearly everything by Tarjan very good in that regard; his papers are among the few that describe (and painstakingly prove) algorithmic improvements (e.g., the inverse-Ackermann Union Find) only to reveal that a simpler implementation with a worse bound consistently performs better in practice.

Correctness

Bertot and Castéran, Interactive Theorem Proving and Program Development is heavy and I'm still going through the book.

Pierce, Types and Programming Languages should be mandatory skimming before entering a debate on "static" and "dynamic" types.

Gries, The Science of Programming changed the way I write programs. It's not that I go full formal on my code, but that I try and structure it so it's easier to reason about. I was just reminded of Dijkstra's Discipline of Programming. The first time I read both books, I did so concurrently. It was a long time ago, and I was less mature mathematically, but I definitely remember finding Gries clearer and more directly applicable, while Dijkstra did a better job of making me think hard about how to best express the meaning of code. Even now, I'd say they're still complementary.

Jackson, Software Abstraction describes an interesting approach to interpolate between testing and formal methods. This book changed the way I write tests. It's also based on a nice application of combinatorial optimisation ;)

Oram and Wilson, Beautiful Code feels uneven to me. Some chapters cover inspiring gems, but many left no mark. A friend suggests Bentley's Programming Pearls or Neuman's Computer Related Risks.

Performance

Golub and Van Loan, Matrix Computations is obviously a good reference for the implementation of dense linear algebra. However, I like this work even more for its clear and precise discussion of performance and numerical precision matters. One can't hide behind big-Oh when discussing linear algebra. Yet, the book is as enlightening and general as classic tomes on asymptotic analysis of algorithms and data structures. Better: that is true for both the implementation and the use of the algorithms they describe. If all software engineering were as well understood as numerical linear algebra, our discipline would be in a good place.

McGeoch, A Guide to Experimental Algorithmics was my bedside companion for the holiday season. On several occasions, I told friends that this is the book I wish I had read ten years ago and that I dreamt of writing the past couple year. It has good rules of thumb and suggestions for everything from designing proper experiments to deriving robust performance models.

Warren, Hacker's Delight is really a fundamental book for me. It's not that bit twiddling tricks are that important, but that I know I can count on Warren's nice exposition if I need to direct someone to a reference. Now nicely complemented by Knuth 4A.

Operations research

Continuous optimisation

Ahuja, Magnanti and Orlin, Network Flows because it describes all the classics. In particular, if an optimisation problem is in P, it's probably in there.

Bazaraa, Sherali and Shetty, Nonlinear Programming mostly for a couple convergence proofs and as a reference.

Chvátal, Linear Programming for its unique (? rare, definitely) and insightful presentation of linear optimisation and of classic duality theorems. I like the sections on Network flows and on Basis factorisation for similar reasons.

Hiriart-Urruty and Lemaréchal, Convex Analysis and Minimization Algorithms because decomposition methods depend on convex nondifferentiable optimisation. I rarely care about general convex optimisation, but it's an unavoidable building block for Lagrangian decomposition methods.

Combinatorial optimisation

Bollobás, Modern Graph Theory mostly as a reference for classic results. I remember having a lot of fun with the section on matchings.

Lawler, Combinatorial Optimization is short but dense. I don't grok matroids, and someone I respect gave me this book and told me it would all make sense once I'd gone through it.

Nemhauser and Wolsey, Integer and Combinatorial Optimization for the dark times when I need to directly think in terms of polytopes and facets, or when I try to generate fancy cuts.

Schrijver, Combinatorial Optimization mostly as a reference for theoretical results. It's exhaustive, so I can use it like the TAoCP of optimisation and as a springboard to other work.

Wolsey, Integer programming when Nemhauser is hard to follow.

Messy stuff

These books help me approach problems that don't fit neatly in any box.

Bertsekas, Dynamic Programming and Optimal Control and Law, Simulation, Modeling and Analysis fill holes left by my focusing on deterministic single-period problems. I use Bertsekas and Law as refreshers when I remember that I'm forgetting something. I can then decide whether to go more deeply in that direction.

Polya, How to Solve It. For the really dark times when it feels like I'm asked to do the impossible. Perhaps it's mostly useful because it distracts me from the immediate task for a couple minutes. Either way, I like to re-read it when I get stuck.

Tufte, The Visual Display of Quantitative Information, along with Hadley Wickham's ggplot2, taught me to think deliberately about presenting results. Our visual cortex is pretty awesome but bad visualisation wastes our brain on distractions.

09 Mar 2014 3:15am GMT

Chatsubo.net is looking for a part-time, telecommute developer who has the following skills:

- ANSI Common Lisp
- Javascript & Node.js
- Unix systems programming
- Web application development
- Couchdb

Would be nice to have
- Database system implementation
- Experience with performance aspects of large memory mapped files

Chatsubo.net is currently working with an innovative startup company on an interesting refiguring of the online shopping experience. The application is built on Common Lisp, Node.js, Couchdb and our own VivaceGraph. We are looking for someone to help us take both this application and our in-house graph database (VG) from prototype to production-quality status. The work would be part-time telecommute to start, with the possibility of becoming full time in the future. Please contact raison@chatsubo.net to discuss.

07 Mar 2014 2:41am GMT

These bindings allow access from the LispWorks GUI to the Perforce SCM.

control-x p e "P4 Edit" control-x p S "P4 Submit" control-x p o "P4 Opened" control-x p r "P4 Revert"

It's been some years since I released version 0.2. Since then I've thrown out the COM bit and now it no longer crashes, even a little bit. Also, it's no longer confined to Windows.

I've been using this (or its predecessor) daily for years. If I have any other users out there I'll be pleased to hear from them as it might improve the chances of there ever being a 0.4.

05 Mar 2014 6:15pm GMT

Senior Common Lisp Developer

Clozure Associates is seeking senior Common Lisp developers to join our team of engineers on an ambitious startup project.

Candidates should have significant professional or open source experience programming in modern Common Lisp. A strong math background is desirable. Other valuable skills and background experience include:

- Embedded systems
- Real-time systems
- Distributed systems
- Signal processing
- Linear systems
- Cryptography
- Communications theory
- Network Protocol Stacks
- Linux device drivers

Locations: Seattle Washington, Boston Massachusetts preferred. Remote work may be possible for highly qualified candidates.

04 Mar 2014 9:50pm GMT

SLIME 2.4 has been released without any exciting release management, but with extensive release notes! :-)

02 Mar 2014 2:40pm GMT

I'm surprised that I didn't know about the @. construct in Common Lisp's backquote syntax. It is equivalent to ,@ except that it licenses the implementation to destructively modified the tail of the list being inlined.

cl-user> (defparameter *x* '(1 2 3))
*x*
cl-user> *x*
(1 2 3)
cl-user> `(a b ,@*x* c d)
(a b 1 2 3 c d)
cl-user> *x*
(1 2 3)
cl-user> `(a b ,.*x* c d)
(a b 1 2 3 c d)
cl-user> *x*
(1 2 3 c d)
cl-user>

01 Mar 2014 4:28pm GMT

Just because I'm attending mobile world congress doesn't mean that everything else stops. It's the end of the month, so it must be time to release sbcl. This month's is a little unsatisfying, because we've only achieved one of the two things I'd hoped for: we've been cautious and conservative after last month's landing of the new register allocator, but we haven't sorted out what's going on to cause the less active architectures to fail to build. There are some workarounds that have been mooted; for one reason and another no-one has had the time to check whether they actually work, and while there's partial progress on identifying the root cause of the build failure on sparc it is only partial.

Nevertheless, minor architectures have been broken before, and no-one particularly benefits from not releasing, so 1.1.16 it is. Actually making the release is a little more challenging than usual: I aim to release by the end of the month, and in practice that means it must be done today, 28th February. However, this is the day that I am returning from Barcelona, so I am less in control of laptop power and connectivity than usual for a release day. And to add to the challenge, I am trying this time to address the valid complaints that the binaries built on my laptop don't actually run on released versions of Linux, thanks to the change in the semantics of memcpy (glibc changed the implementation in its version 2.14 to exploit the freedom given to return undefined results if the source and destination overlap) and the behaviour of the linker and versioned symbols.

So over breakfast I dusted off my squeeze chroot (that doesn't sound dodgy at all), and tried to work out how to get a runnable version of SBCL in there at all (answer: build using clisp and link to the chroot's libc). At lunchtime, I used the café's wireless to check for any last-minute changes, and in the airport I found a power socket, so I started the release build. Of course it didn't finish before the gate opened, and in any case I wasn't going to chance uploading sbcl binaries over the free airport wifi (15 minutes, woo!)

I've performed some release stunts before. SBCL 0.9 was released by William Harold Newman and simultaneously announced by me at the first European Common Lisp Meeting in Amsterdam in 2005. Last year, I released SBCL 1.1.8 "live" as part of a lightning talk at the European Lisp Symposium in Madrid. But I think this is the first time that an SBCL release was even partially effected from the air. Next stop, space?

28 Feb 2014 10:10pm GMT

Elias Martenson kindly pointed out that I forgot a progn around ,@body:

(defmacro with-java-stack-trace (&body body)  
  `(handler-case   
    (progn  
      ,@body)  
    (java:java-exception (e)  
     (print (#"getMessage" e))))) 

27 Feb 2014 4:28pm GMT

Following up on the java stack trace post, here's a little macro that can be used to wrap the lisp code that (eventually) triggers the java-side error:

(defmacro with-java-stack-trace (&body body)  
  `(handler-case   
    ,@body  
    (java:java-exception (e)  
     (print (#"getMessage" e))))) 

Note the use of the java:java-exception in the handler-case clause so that we don't inadvertently trap lisp errors.

27 Feb 2014 12:57am GMT