• 2011-06-19: ABQ Lisp/Scheme
• 2011-07-05: SunLisp (Florida)
• 2011-07-05: Toronto Lisp Users Group
• 2011-07-12: lispnyc

There is a single namespace for packages in Common Lisp.

There is also a single ASDF system namespace.

Please, make sure you use the same prefixes in both!

To pick a random bad example: system name cl-unification, package name unify. Do not do this.

Just pick one, please. It's getting crowded.

After tonight’s TC Lispers Meeting, I had a renewed interest in figuring out why C-<right arrow> didn’t work for me in Org-Mode or Paredit.

After a whole bunch of running in circles, I have discovered a combination that works (with these clues). I have my TERM variable set to xterm-color. I configured the Terminal.app using its Keyboard settings to have it send the string “\033[1;5C” for C-<right arrow> and “\033[1;5D” for C-<left arrow>. (The “\033″ is the escape key.)

This works for me even through screen.

Bonus.

Slime's slime-indentation contrib now also provides support for named indentation styles. Add a line like this to source files to specify a style:

;; -*- common-lisp-style: modern -*-

Predefined styles are: basic, classic, modern, and sbcl. See C-h v common-lisp-style for more details.

You can also define your own styles:

;;; in .emacs, after slime-setup.
(define-common-lisp-style "personal"
   "My own eccentric style."
   (:variables
     (lisp-lambda-list-keyword-alignment t)
     (lisp-lambda-list-keyword-parameter-alignment nil)
     (lisp-loop-indent-forms-like-keywords t))
   (:indentation
     (if (4 2 2))))

See C-h f define-common-lisp-style for details.

If you define a style for use in the source-files of an open source project, please consider submitting it for inclusion.

Ps. in case you're wondering, you can gain access to all these goodies and more by adding slime-indentation to your slime-setup call:

;; Maybe slime-indentation will be part of slime-fancy at some
;; point, but it isn't yet.
(slime-setup '(slime-fancy slime-indentation))

Tip of the day. Don't write:

(defun foo-loop (foo) (loop ...loop body...))

Instead, write:

(defun foo1 (foo) ...loop body...)
(defun foo-loop (foo) (loop (foo1 foo)))

It's a small thing, but it makes it much easier to debug the loop while it's running. If you need to instrument it, you can just add whatever code you need to FOO1 and recompile it.

If you open code almost anything inside the body of an endless loop, it becomes much harder to intercede -- and interactive development is all about intercession with running code.

Almost exactly four years after I announced the availability of the first iteration of the SBCL cvs->git mirror (and a few more years after the cvs->arch mirror even!), we now have an official SBCL repository! Many thanks to Nikodemus for doing all the heavy lifting! (-:

I’ve stopped the (now defuct) cvs->git mirror. In its place, there is a new repository that mirrors the official git repo. To get the old, now static repo, see sbcl-cvs-import.

If you are a committer and have any old checkouts around, please make sure that you follow the procedure for eliminating unnecessary branches / tags.

SBCL 1.0.49 has been released. I already blogged about some of it's features, so I won't repeat myself.

On the dev front, SBCL official upstream has as of today moved to Git:

git clone git://sbcl.git.sourceforge.net/gitroot/sbcl/sbcl.git

to get your clone. The CVS repository remains open for anon access, but will not be getting any new updates.

This changes SBCL version numbers a bit. If you see a version number like this: 1.0.49.3.foo.2-f48ea2d-dirty this is what it means:

• 1.0.49: first three numbers come from the latest release. The last digit is incremented approximately once per month, as before.
• 3 the fourth is the number of commits on origin/master since the release.
• foo is the name of branch being built.
• 2 is the number of commits on that branch but not on origin/master.
• f48ea2d is the abbreviated SHA1 has for the current commit.
• -dirty is a marker for builds from dirty trees, ie. ones containing uncommitted changes.

As long as you don't have local changes, you should only see version numbers containing the first four digits, though.

svn co svn.common-lisp.net/armedbear/trunk abcl

Xach posted recently about Fighting blog spam with Common Lisp as a short example of using lisp to solve everyday programming problems.  Here’s one I made last weekend.

The Problem:

My wife belly dances, and we frequently do some light video editing before posting things to youtube.  One of the annoying chores is making title cards, usually white text on a black background that we put at the beginning and end of each video to state time, place, etc, and then fade in/out.  An example:

Text should be large enough to fill the screen, centered, and all the same size.  For awhile I made these in Gimp, then made them in HTML and took screenshots, and finally said screw it and wrote a small helper program.  I don’t know how to use Gimp effectively, and jiggling font sizes in HTML is a pain.  I’m sure there are better solutions, but it was faster (and more fun) for me to write some lisp.

The Solution:

To make title cards, I wrote a little program called “Titler”.

Like Xach’s project, I started with (quickproject:make-project "~/src/lisp/titler/" :depends-on '(vecto iterate))

From there I banged away at it for a little while, found some .ttf files on my system and got the basic generation done using vecto’s string drawing functions. The only tricky bit was to determine the optimal font size. Vecto provides a string-bounding-box function that will give you pixel dimensions for a given string at a given font size. I made a function that uses newton’s method to iteratively try different font size values until we get one that fits on the title card and takes up more than 75% of the width. I’m almost positive there are corner cases where my implementation won’t converge on a solution, but it works pretty well for now.

For the next video I can make easy titles:

(make-title "www.ShamblingShimmies.com

May 26, 2011
Sun Center
Gainesville, FL" 640 480)

Code is at https://github.com/ryepup/titler, and you can see the results (and my wife fire dancing) at youtu.be/Wicy0B7Ol5Q.

I am releasing a new version of the USerial library. New in this version:

• Fix (make-int-serializer) to be big-endian 2′s complement
• Add :symbol and :keyword serializers
• Add (make-vector-serializer)
• Add (make-key-slot-serializer) and (make-key-accessor-serializer)
• Add (define-serializing-funcall)

Obtaining

• The USerial home page: nklein.com/software/unet/userial/
• The tarball: userial_0.8.2011.06.02.tar.gz
• The signature: userial_0.8.2011.06.02.tar.gz.asc
• The main git repository: git.nklein.com/lisp/libs/userial.git/
• Browsable git mirror: https://github.com/nklein/userial
• Issue reporting: https://github.com/nklein/userial/issues

I was recently reminded of a presentation that I gave last year about Weblocks.

Here’s one slide from that presentation:

Today, I started from scratch in an empty account on an eight-year-old Linux box. I installed Quicklisp and used it to install Weblocks. I had a Weblocks server up and running in under three minutes.

Noticed via Twitter that Joey Comeau of "A Softer World"-fame has been doing some programming in Lisp. I liked the way he put it:

Joey: (4:01:05 PM) maybe i should take up a self abusive hobby
Joey: (4:01:08 PM) like lisp programming
Ryan: (4:01:20 PM) haha
Ryan: (4:01:23 PM) sec phone
                   after the phone call i leave the computer and don't come back
                   the next day
Joey: (9:20:29 AM) I am learning common lisp

With apologies to Joey and Emily:

(And here's one of my favourite strips.)

I've just released a new version of Declt, my Texinfo reference manual generator for ASDF systems. This release contains only one bugfix: when trying to create links to source files, Declt now checks whether the files actually exist or not.

Tracking this bug down had the side-effect of exhibiting a misfeature of SBCL's introspection facility: the COPY-<struct> functions (automatically generated by defstruct calls) have their definition source set to target-defstruct.lisp which is an SBCL source file. It would make more sense to set it to the file containing the defstruct call instead, as is already the case for constructors, predicates and accessor functions. Patch sent to the SBCL developers.

It's that time of the month again.

SBCL's frozen for testing, in preparation for 1.0.49 release due next weekend.

Some things on note this month:

• Things like

  (defun foo (f &rest; args)
    (apply f :bar t args))

  typically no longer cons the argument list on the heap.
• Functions from files loaded as source have source location information associated with them.
• Deadlocks on mutexes and spinlocks are detected.
• --script commandline option now also works with standard input, and is generally more shell-scripting friendly.
• Using call-next-method with explicit arguments in safe code is much faster in the common case of required arguments not changing. Eg:

  (defmethod foo :around (x &key; bar)
    (call-next-method x :quux t :bar (compute-default x bar)))

• Few instances where interrupts were disabled needlessly have been fixed, leading to easier to debug code.

That's not the complete list by any means, which is why you should grab the latest from git, eyeball the NEWS, and give it a whirl -- and report any regressions.

It's been two months since ELS 2011 is over and I didn't have the time to give my impressions as the programme chair until now. I still don't have much time, so it's going to be quick, but before that, here are two announcements in this transition phase:

• the proceedings are now available as a single PDF file on the symposium website.
• eventhough a couple of options are already under consideration, we are still looking for volunteers to be next year's local chair. If this is of interest to you and you have the ability to locate ELS 2012 at your place, please contact us.

About ELS 2011 now. I'd say that it was a great success, perhaps the most successful of the 4 occurrences. We got two full days of interesting talks on various topics and of different forms. We gathered more than 60 persons from all around Europe and also a quite a few from the US (ITA contributed greatly to that :-). The final panel was very nice (something quite rare these days). The local organization went also pretty smoothly.

In retrospect, and as the person in charge of the contents, I have several hypothesis on what makes such an event successful, especially in those days where academic events suffer from a decreasing level of attendance.

1. Having a "special focus" helps. Having an important one (like Parallelism and Efficiency) helps even more.
2. Having a regularly occurring event also helps a lot, especially for academicians. This is not new, but it really is important to know that ELS will always happen roughly at the same period every year. Academicians (at least) need to plan their work that long in advance.
3. I also like more and more the formula of a "mixed" conference where you invite formal (technical) papers, demonstrations, position papers etc. Some people know how to write technical papers, some people don't, are not so good at it, or just don't have the time for it, but it doesn't mean they have nothing interesting to say. ELS 2011 had about 50% formal presentations and 50% demonstrations. I decided to create the different sessions not by grouping talks based on format, but based on topic, and I think this went pretty well. The sessions didn't look completely heterogeneous to me.
4. Having invited speakers helps. This is of course not new at all, but here, I would just like to answer something I've read recently about ELS 2011; a blogger (I don't remember who) saying that he didn't understand why 2 out of the 3 guests were not speaking about Lisp at all. My opinion on this is simple: as a community (in general; not speaking of Lisp in particular), we have a tendency to be separated from the rest of the CS crowd and loose track of what's going on next door. We don't talk to each other enough. Hell, it's already so difficult to stay up-to-date with your own crowd sometimes! So when I attend a very focused conference, like a language-specific one, I'm always happy to be served a couple of talks that can broaden my view of things, even if they have no direct connection with my own activities. In our specific case, I was very happy with Craig Zilles'presentation and I can see how this could be of interest to us in the long term.

So, that's it for now. Stay tuned for next year's location, and in the meantime, remember that some other Lisp events are already planned: ECLM in Amsterdam, and ILC in Kyoto... simply my favorite place in the world!

EyeCarePro.net (www.eyecarepro.net) is looking for a full time SBCL programmer to help manage and improve our main website builder application.  No relocation required – North American working hours, 5+ years of SBCL experience (Hunchentoot / Debian) with strong communication skills.   Contact DanielR@eyecarepro.net for more details.