Zach's Journal

Here are a few Lisp-related links I liked in April:

• A cute read-macro dispatch scheme. Worried about running out of characters for read macros? #/foo/ to the rescue!
• Daniel Weinreb's ECLM 2008 recap (Dave Moon has a cool comment)
• Edi Weitz's ECLM 2008 recap (including MP3s of several talks)
• Limp: Lisp in Vim
• Lisp for the Web. A nice baby-steps guide.
• Getting CLOS by Joe Marshall. A teaser.
• Lisp-centric "Good Easy" by Bill Clementson.

And here are the coming Lisp-related meetings in May I know about:

• May 4: CRACL (Los Angeles)
• May 8: Lisp Stammtisch (c-base, Berlin)
• May 13: lispnyc (New York City)
• May 16: Chicago Lisp meeting
• May 18: ABQ Lisp/Scheme meeting (Albuquerque)
• May 22: ELS 2008 (Bordeaux)
• May 22: lispvan (Vancouver) featuring Drew Crampsie and Lisp on Lines
• May 27: Boston Lisp meeting
• May 28: Hamburg Lispers
• May 31: Intro to Lisp Workshop in Chicago. Three hours of practical advice on getting started with Common Lisp! Awesome! Volunteers are needed, so if you're in Chicago, go help them out.

If you're having a meeting in May and I didn't list it, let me know.

Last year, while creating AutoMotivator, I threw together a picture of John McCarthy with fake inspirational text. To my surprise, a lot of people really liked it.

I recently extended the software to create bigger AutoMotivator images for printing. Here are a few of the test images (click for full size):

Suitable for printing at US letter size

Suitable for printing at A4 size

Print one out on your company laser printer and hang it on your cubicle wall. Extra motivation guaranteed or your money back.

If you use a pre-1.0.8 SBCL with CVS SLIME, it won't work.

When I'm trying to debug functions, I often add (declare (optimize (debug 3))) to the top and then use "v" in sldb to jump directly to the location of the error in the source. Then I take out the declare bit after I'm done troubleshooting.

To automate this, I added an option to compilation that uses the new experimental SB-EXT:RESTRICT-COMPILER-POLICY function to compile with maximum debug. That is, C-u C-c C-c will recompile individual forms at debug 3. You don't have to manually add and remove it, and you don't have to run your whole system with elevated debug.

It only works on SBCL 1.0.8 and newer, though. I think it'd be handy for all backends, but I don't know how to add it.

In 2000, William Harold Newman announced his new Lisp project, SBCL, to comp.lang.lisp:

I'm working on SBCL,
        http://sbcl.sourceforge.net/
a variant of CMU CL which should be easier to
maintain than CMU CL. Some of the changes involved -- especially
making the system bootstrap itself cleanly -- involved major surgery
on the CMU CL code base, not just local patches, and the result is a
distinct version of the system.

I consider the new release of SBCL (sbcl-0.6.0) to be alpha quality,
unstable but fairly usable. 

For eight years he's been working on SBCL and making new releases every month. But a few weeks ago, he stepped down:

I'd like to resign as project administrator. This decision is not affected by sbcl-1.1 release issues: I've been absently thinking about it for months, and actively for the past month or so. The decision is hardly affected by anything about the SBCL project at all, in fact. Other things in my life have chewed up a lot of my energy and motivation, and it is far harder for me to deal with any extra responsibilities than it used to to be, and SBCL is just one of the casualties.

Christophe Rhodes, Juho Snellman, and Nikodemus Siivola will now manage SBCL releases.

I started using CL and SBCL after Bill's busiest period of SBCL hacking, but he paved the way and made it easy for new people to become vital developers of the system. The CREDITS file lists nearly 60 contributors of great and small features and fixes.

Thanks for creating SBCL, Bill!

After two failed attempts, I finally made it to the Boston Lisp meeting on Tuesday. I enjoyed the two talks.

ACL2 is a theorem-proving system, and people have used Emacs to drive it for many years. To help people learn ACL2 without learning Emacs at the same time, Peter Dillinger worked on ACL2s, an Eclipse-based interface to ACL2. In his slides he compared the original Emacs interface to a racecar: fast, highly effective in the hands of experienced users, and unforgiving of errors. ACL2s is designed to be easier to learn and more forgiving, like a family sedan.

This reminds me of Cusp, though the original Emacs interface for ACL2 seems more primitive than SLIME. Most of the questions were about with the capabilities of ACL2 rather than the ACL2s interface. I was more interested in how easy it is to extend ACL2s than what was involved in proving theorems. Does it involve writing more Java, or more Lisp? Or something else? I didn't ask Peter about it, though.

Part of the Q&A drew a laugh:

Q: Why not add these advanced features to the Emacs ACL2 interface?

A: Well...um...Eclipse is designed to be extensible, for programming stuff...

Q: ...

Wag: Just say Eclipse can do multiple threads!

A: Multiple threads! ACL2s is using four threads in this demo!

Hans's talk about the BKNR data store was interesting. It's a simple, tested, documented system for object persistence. It was created to avoid the need to install, maintain, and tune a relational database system, and figure out some way to map relational tables to Lisp objects; instead, it's standard Common Lisp all the way down.

The design decisions have worked out well for Hans's applications:

• Use the MOP for transparent persistence of instances
• All objects are kept in memory
• Persistence is via a transaction log
• Only one writer may be active at a time

Hans was clear that this is not the perfect solution for all purposes. This setup can fit the needs of many applications, though. Hans demonstrated a website with over 400,000 objects; it took up about 50 megabytes on disk and about triple that in memory. Initializing the objects at startup took a minute or two, but, as Hans noted, "Lisp hackers are used to not restarting very often."

The timing for his talk was good for me. A few weeks ago I extended AutoMotivator to have a user and poster management system, and I wrote a simple persistence system from scratch. Although it was fun to make and was an educational first use of the MOP, challenges of storage, querying, and schema evolution have already cropped up. BKNR has the advantage of being small, mature, documented, and tested by real-world projects with hundreds of thousands of objects. I'd like to switch from my home-grown system to BKNR's storage system soon.

After the talks ITA provided pizza and Indian food, and I got to meet several Lisp hackers in person that I had only spoken with online. We wound up chatting for hours about various topics.

Though several people I know online were there, there wasn't much in the way of introductions and nobody wore much identifying material, e.g, name tags. A few people identified me by my Save Lisp and Die shirt, but I was a little too shy to go around asking people who they were.

Even though I didn't get home until 2AM Wednesday, I'd like to go to the next meeting on May 27th. You should go too!

• Sven Van Caekenberghe: Common Lisp: First Contact
• Rahul Jain: DefDoc, a presentation from the most recent Boston Lisp meeting [video]
• grokcode: joke generation in Common Lisp
• Nicky Peeters: Lisp bundle for TextMate

Vecto 1.2.1 is out. This release adds support for circle arc paths, adapted from Ben Deane's curve library.

I have a few more pending features that should become part of Vecto soon, including tilty ellipses, arbitrary fill functions (both courtesy of Ben, again), and simple gradient support courtesy of Ramarren. They'll make it even easier to draw really pretty things with Vecto.

Enjoy!

The Toronto Lisp meeting is tonight. And Peter Christensen has written about the recent Chicago Lisp meeting, with info about the next meeting on April 18th.

Rob Henderson is on a quest. A quest to develop a game in Common Lisp, for Windows. Go, Rob!

Conrad Barski M.D. has a new project: a Lisp comic book called Land Of Lisp. It's cute, funny, and I was completely delighted and surprised by the end of it.

Once again, Circumstances conspired against my attendance of the Boston Lisp meeting, but Bruce R. "Doings" Lewis put up a few pictures. 70 people showed up!

Mikael Jansson really really really really really reall wants you to read his blog. So go read it!

The meeting sounds like it was a success:

There were many questions for Tim and Tim afterwards. Everyone seemed to enjoy the demo. I want to thank Tim and Tim for coming, they did a really good job of presenting. Who knows, we may even have gained a couple new Lispers after a presentation like that. It really helped to observe how veteran Lispers wrote their code. It helped me confirm I was doing things right as well as showed me some things I didn’t know.

The Hamburg Lisp meeting was also last night. Tonight sees the Montréal meeting and the Berlin meeting. Tomorrow is the St. Louis meeting, Sunday is the Los Angeles meeting, and Monday is the Boston meeting! I wanted to go to all of them, but only Boston is feasible.

Check out the Lisp Meeting calendar if you want to know if there'll be a meeting soon near you.

Dan Weinreb explains conditions:

When you design a function, you should first think of all the possible kinds of (correct) outcome. Then you should decide how each outcome will look to the caller: certain specific returned value(s), or certain specific conditions. This all becomes part of the contract for the function.

jwz reminisces about MOST-POSITIVE-BIGNUM:

Well, I was poking around in the system's basement one day, and realized that their implementation of bignums did have an upper limit! A bignum was implemented as an array, with no facility to tack on a second array, so the limit was related to the size of the length field in the array header (instead of being limited by available memory).

So I went and consed up MOST-POSITIVE-BIGNUM.

Kenny Tilton has a blog. Sometimes he even writes about Lisp:

Over a couple of years we built a system consisting of eighty thousand lines of Lisp, having probably thrown away another fifty thousand along the way. We were in the classic situation described by Paul Graham in On Lisp: not knowing exactly what program we were writing when we set out on our mission.

Enjoy!

MCL 5.2 source is now available. Want to get it fast? Try these torrents:

• MCL 5.2 DMG
• MCL 5.2 bzipped tarball. Tarball made by Paul Khuong (thanks Paul!)

If you're using a Mac and want to get all the right stuff, use the DMG. The tarball is for people like me who don't have a Mac handy but want to peek at the contents anyway.

I got a note from Paul Beel about a new meeting:

Well, we are kicking off our first meetup next week. We are calling it the Indiana State University Programming Meetup. This is our first time meeting. We hope to meet on an ongoing basis. This meetup is open to the public and always will be. So this is not only for students, this is for anyone that is interested in programming. The meeting will be held Wednesday, March 26th at Indiana State University, Root Hall in the Unix Lab. The meeting starts at 5:30pm. At this first meeting, pizza and soda will be provided.

It would be great if you could put it on the calendar and even blog about the details if you thought it deserved that.

I've added it to the Lisp Meeting calendar, too.

Can anyone tell me how the Bay Area Lispniks meeting went yesterday?

I count no fewer than eight Lisp-related meetings in the next few weeks.

• March 18th, 7:30pm: Bay Area Lispniks at Suraj Indian Restaurant in Redwood City
• March 21st, 7pm: Chicago Lisp Meetup, Ambrosia, 1963 North Sheffield
• March 26th, 19:00: Hamburg Lispers at Marilu in Ottensen
• March 27th, 19:00: Berlin Lisp meeting, c-base
• March 27th, 7pm: Montréal Scheme/Lisp User Group Meeting, Room 3195, André-Aisenstadt Building, Université de Montréal
• March 30th, 7pm: CRACL (Los Angeles) at Royal Clayton’s Pub in the downtown Arts District
• March 31st, 6pm: Boston Lisp Meeting at MIT, room 34-401B
• April 3rd, after 6pm: Toronto Lisp Meetup at Bloor St. Fox and Fiddle

All times are local.

To keep track of the meetings, I started a Google Calendar page with the info. I'd like to keep it up-to-date with all upcoming Lisp-related meetings.

Bill Clementson wrote about yesterday's lispvan meeting, and included Brad Beveridge's slides in OpenOffice format. I've converted them to PDF for slightly easier viewing, you can find them here.

The slides are interesting, and I can't wait to check out the video!

The February meeting of the Vancouver Lisp User Group is tonight, February 28th. Brad Beveridge will give a talk on "Doing Evil Things with CL".

Speaking of doing things, there have been 30 responses (so far!) to my practical Lisp 2008 post. Only a couple were evil, though, so you probably have something to learn from Brad's talk.

A little more than three years ago there was a thread in comp.lang.lisp about what people were working on in Common Lisp. I found the replies, some summarized here, quite inspirational; they were from people doing practical stuff (even Real Work) with Common Lisp, beyond things like going through Project Euler or doing exercises from SICP. (Not that those aren't fine things to do, but.)

Let's update this. What are you using Common Lisp for in 2008? What are you using to do it? I'll start:

I mostly use Common Lisp to make graphics toys at Wigflip.com. To that end I'm always looking for new ways to produce or consume graphics-related things. For example, I'm adding support for processing OpenType fonts to ZPB-TTF and making a hybrid of Skippy and Vecto to produce simple vector-oriented animations. I'd also like to add APNG support to ZPNG.

I primarily use SBCL on Linux, x86 and x86-64, with Emacs and SLIME. For deploying all my website stuff I use Edi-ware extensively: Hunchentoot, HTML-TEMPLATE, and CL-WHO. I use CLSQL for a few things too. For graphics work, I use mostly my own libraries.

How about you? Leave a comment and let me know.