Tuesday, September 27, 2011

Finding Changes to Quicklisped Software

In my current project, I'm working with Allegro CL in modern mode. Modern mode is a non-standard mode supporting mixed-case symbols in the reader. This means that in modern mode, the two literal symbols :foo and :FOO are different things. This is different from other lisps, that convert names of literal symbols read to uppercase before interning them. This is why :foo, :Foo and :FOO all mean the same :FOO, by default.

I am using the excellent Quicklisp package management utility to pull all dependencies that a certain package needs. With ACL in modern mode, though, I had to fix several libraries that used all-caps symbol literals (like #:FOO, NIL etc.). The fixes were mostly trivial, but when I had all the stuff running that I wanted, I had modified several of the libraries that I had installed with Quicklisp.

I am planning to import all the external libraries into git repositories and not use Quicklisp in production. I still want to be able to easily update to new upstream versions and also send the changes that I made myself upstream. To make the process of finding what I've changed easier, I envisioned a tool that tells me which of the libraries that I had installed with Quicklisp have local changes, and what these changes were. I asked Zach Beane for help, and he promptly came up with a small function called QDIFF that performs a diff between Quicklisp's base version and the locally extracted version of a library. I hacked the tool slightly to make it work with Allegro CL and iterate over all locally installed systems. It is available as a gist.

Zach supplied a SBCL specific way to run the diff command. I added one based on ASDF:RUN-SHELL-COMMAND, which apparently prefixes all output lines with "; ". I don't like that, but I also did not want to pull in a shell compatibility layer into this self-contained thing.

I praised Quicklisp in the past, but there is nothing wrong with doing it again. Open Source Common Lisp has become so much better with it, and I need to thank Zach again for being so passionate about making the Common Lisp world better! Thanks, Zach!

Share:

2 comments:

  1. What's the plan for synchronizing your local git repository with the upstream? I get it that this lets you detect upstream changes if you run it periodically. What do you do then? Separately sync with upstream repositories? Or use the diff to update your local copy?

    I am curious because we do the same: we blow all the libraries we use into our own local repositories. But that doesn't leave us in a good position to keep track of upstream modifications. So any clues would be helpful.

    ReplyDelete
  2. What we do is create our own github repositories with versions of the software that we use. Those repositories will be referenced as git submodules. We'll then use them to submit patches upstream and track changes. This is far from perfect, but I think it is better than having one big tree of imported projects with local changes in that it will be easier to keep track of modifications on either side.

    ReplyDelete