 |
New Artisans LLC Code to do what you need. |
Ready Lisp version 20080428 now available
There is a new version of Ready Lisp for Mac OS X available. This version is based on SBCL 1.0.16, and requires OS X Leopard 10.5. The most notable change from the previous version is that 64-bit mode and experimental threading are no longer supported, since both have been known to have issues on OS X, while the purpose of Ready Lisp is to smoothly introduce Common Lisp to new users.
What is Ready Lisp? It’s a binding together of several popular Lisp packages for OS X, including: Aquamacs, SBCL and SLIME. Once downloaded, you’ll have a single application bundle which you can double-click — and find yourself in a fully configured Common Lisp REPL. It’s ideal for OS X users who want to try out Lisp with a minimum of hassle. The download is approximately 76 megabytes.
There is a GnuPG signature for this file in the same directory;
append .asc to the above filename to download it. To
install my public key onto your keyring, use this command:
$ gpg --keyserver pgp.mit.edu --recv 0x824715A0
Once installed, you can verify the download using the following command:
$ gpg --verify ReadyLisp.dmg.asc
For more information, see the Ready Lisp project page.
FP techniques in Lisp: Data sharing
Recently I've been porting a C++ accounting system to Common Lisp. And after only six weeks, the port is nearly complete — a feat I credit to the power of the Lisp language and the facilities it offers I'd been forced to replicate in C++.
But as the port nears completion, I find myself questioning some of the design decisions. Did C++ force me down a path where Lisp can offer a better alternative? Read More...
Fixed a few bugs in Ready Lisp
A couple of pathname issues were discovered in the release of
Ready Lisp that was posted yesterday, leading to the inability to
load asdf-install (or use it). These have been fixed
in the new release uploaded today. If you now use
asdf-install and choose a “system-wide” installation,
the installed packages get saved in your Application bundle.
However, due to the way that asdf-install itself
works, if you then move your application bundle to another
directory, symbolic links in the systems directory
will get broken. So I recommend installing new packages into your
home directory instead.
Also, the sources for SBCL are now included, meaning that if you
use M-. (jump to definition) and pick a function like
mapcar, it will drop you into the source code for
SBCL’s mapcar implementation.
The new version is available here (the old link still works, it is now a reference to that one).
Lastly, I’ve created a new home page for the Ready Lisp project, which now lives here.
New version of Ready Lisp for Mac OS X available
There is a new version of Ready Lisp for Mac OS X available. This version is based on SBCL 1.0.12.17, and requires OS X Leopard 10.5. The most notable change from the previous version is that it is now fully universal, supporting PowerPC and 32- bit and 64-bit Intel machines. Also, threading has been turned on for Intel processor. See the NEWS below.
What is Ready Lisp? It’s a binding together of several popular Lisp packages for OS X, including: Aquamacs, SBCL and SLIME. Once downloaded, you’ll have a single application bundle which you can double-click — and find yourself in a fully configured Common Lisp REPL. It’s ideal for OS X users who want to try out Lisp with a minimum of hassle. The download is approximately 87 megabytes.
There is a GnuPG signature for this file in the same directory;
append .asc to the above filename to download it. To
install my public key onto your keyring, use this command:
$ gpg --keyserver pgp.mit.edu --recv 0x824715A0
Once installed, you can verify the download using the following command:
$ gpg --verify ReadyLisp-1.0.12-10.5.1.dmg.asc
Below is a full rundown of what’s new.
Now fully universal
Ready Lisp is now fully universal, and runs on the following platforms:
- Intel 64-bit
- Intel 32-bit
- PowerPC 32-bit
There is no port of SBCL to 64-bit PowerPC. Experimental threading has been enabled for both Intel platforms.
Updated versions
The following pieces were updated:
- SBCL, to version 1.0.12.17
- SLIME, to CVS version 2007-12-06
Aquamacs remains at version 1.2a.
Full Info documentation
Info documentation for the Common Lisp pieces is now bundled in.
Just type C-h i to read it. Also, when editing Common
Lisp files, you can type C-h f to instantly access the
HyperSpec index. In Emacs Lisp files, C-h f will get
you help on Emacs Lisp functions.
There is also HTML and PDF versions of all documentation in:
Ready Lisp.app/Contents/Resources/htmlReady Lisp.app/Contents/Resources/doc
More libraries
There are a few more Common Lisp libraries bundled in the core file with this release:
CL-FADLOCAL-TIMESERIESMEMOIZECL-PPCRE
I find these libraries very handy, but mainly I’m including them
because the upcoming release of my CL-Ledger accounting tool
depends on them, so it will work for Ready Lisp users
out-of-the-box. See the “doc” subdirectory above for documentation
on how to use these libraries (except MEMOIZE, which
does not have separate documentation; use
memoize:memoize-function to mark a function as
memoized).
Common Lisp web servers
Recently at work my manager asked me to create a server solution that was both, “Fun, and easy for me to get things running quickly in.” Well, to me that’s a roundabout way of saying Common Lisp, so I started looking at possible solutions based on that platform. The solution will run as a webserver in a potentially high-demand scenario, so I figured it would pay to compare the options available to me.
Unfortunately, I did not have equal platforms on which to create these test results. If this were my only task this week, I would have setup a dedicated Linux machine and created identical tests for each setup described below. Because I do not have this luxury, some of the results may be due solely to where and how I ran them. So please take these numbers with a huge grain of salt, since you may see very different results in your own environment.
First, I wanted to test Apache serving static files, to get a feel for what Lisp is up against. On my MacBook Pro, running OS X 10.5.1 and Apache 2.2.6, Apache is able to serve a simple HTML file at roughly 4000 requests per sec. This was determined by repeatedly running ApacheBench, using 1000 accesses and 10 concurrent threads.
Next I tried Hunchentoot, serving the exact same file. I’m using SBCL 1.0.12.6 on Intel OS X (32-bit), with threading enabled. Note that threading is not officially supported on this platform, and was something I had to explicitly enable during the build process. What you get from MacPorts will not have threading enabled. It could be this that led to some of the results I saw.
Anyway, Hunchentoot in this scenario serves between 250-400 pages per second. Honestly, I’m not sure if that’s good or bad for a pure-Common Lisp implementation, but I did find myself a bit disheartened. Also, Hunchentoot on OS X does not handle worker thread exhaustion very well. I’m certain that part of this is due to the preliminary thread support on OS X, but then again, the same tests has troubles on Linux as well (see below). Using 1 concurrent thread in ApacheBench, Hunchentoot does fine. At 5 threads it does fine most of the time. At 10 threads, Hunchentoot has a tendency to drop requests, causing ApacheBench to stop working altogether. I had to try several times in a row before I could get all 1000 page loads to complete.
Next I tried Portable AllegroServe with the same SBCL version. I
used paserve 1.2.47-vbz-0.1.4, a version
custom-fitted for use with SBCL. The numbers here were a bit more
promising: on average, 1000 pages/sec. The real advantage, though,
is that listener thread exhaustion only causes AllegroServe to wait
until another thread is available. I was able to run ApacheBench
with 1000 concurrent connections and AllegroServe didn’t bat an
eye.
Since I don’t have mod_lisp running on my OS X box,
the next tests all used Linux virtual machines running under VMware
Fusion. I used 64-bit CentOS 5 (x86-64) for all tests.
The Apache baseline is much slower in this case, as expected. Now Apache serves direct files at ~1200 pages/sec. Hunchentoot running behind mod_lisp serves pages at around 190 pages/sec. The nice thing, though, is that threading problems are non-existent. What’s strange, however, is that if I increase the number of concurrent access, performance actually goes up! At 100 concurrent accesses (as opposed to 10), Hunchentoot behind mod_lisp is able to serve pages at around 330 pages/sec. I have no idea why this would be the case. Also, I’m not doing static file tests this time, but using the dynamically generated default page for Hunchentoot.
If I access Hunchentoot in this setting directly, it doesn’t break off connections the way it does on OS X, but it does stall them. As a result, with 10 concurrent accesses, it serves up data at around 30-50 pages/sec. So using mod_lisp is definitely a huge win. Also, at 100 concurrent accesses, I was able to send the SBCL process into a 100% CPU burn, from which it took over a minute to recover — even after aborting ApacheBench. At 5 concurrent access, there was less contention and it served data at around 200 pages/sec.
For the last scenario, I switched to another Lisp implementation
altogether, this time to Armed Bear Common Lisp. I
figured I would try running a Java servlet under Tomcat, thereby
leveraging the stability and great threading support I’ve come to
expect from the Java VM. Also, I can easily integrate with other
Java code we have in house, which is sure to become a requirement
if the project succeeds. So I created another 64-bit CentOS 5
virtual machine and loaded Tomcat5 using JPackage. I also built my own
tomcat-native package, so I could have Tomcat running
as fast as possible. This setup used Sun’s JDK5 JVM, Tomcat 5.5,
and Armed Bear version 0.0.10.
Rendering a dynamic Lisp page, the Tomcat solution sees speeds on average of 330 pages/sec, in the same scenario where Hunchentoot behind mod_lisp offers 30-50 pages/sec (due to thread contention). Also, concurrency with the Tomcat servlet is no problem at all; with 100 concurrent accesses, speed is simply not affected. Even at 1000 concurrent accesses, nothing really changes. This could be due to smart caching on Tomcat’s part, or just to great thread handling.
I did not try AllegroServe on Linux, because I think running on the Java VM will be smart for other reasons not relating to Common Lisp. I was a bit disheartened by Hunchentoot’s performance and threading behavior, but at the same was quite pleasantly surprised by Armed Bear. I do hope the author of ABCL continues to put effort into his project; and I’m crossing my fingers that basing code on a 0.0.10 release won’t end up being a huge mistake. If it does become a problem, though, I should be able to switch over to Groovy pretty quickly, without changing any of the framework at all. It’s just that using Common Lisp would make this task such a joy.
CL HyperSpec Info pages in Emacs
I just discovered the following blog article by Bill Clementson, from way back in 2003. Luckily, the links still worked, so I was able to get Info pages today for the Common Lisp HyperSpec courtesy of the GCL project.
Once installed, I found I could not easily lookup documentation
for, say, mapcar, because it’s actually on the page
for mapc. But SLIME’s
hyperspec.el contained the indexing info I needed to
write a new module which fires up the Info system on the correct
section for the symbol you want defined.
This new module is called cl-info.el and is
available from my Lisp
repository. It rebinds the standard Emacs key for function help
(C-h f) to lookup help in the HyperSpec instead, if
you’re in a lisp-mode buffer.
NOTE: A fellow Lisper pointed me to
this blog entry which offers a much nicer way to get the
HyperSpec in Info form. It’s a little more work, but the quality of
the result is superior and it has an index! Also, it makes my
cl-info.el unnecessary, by relying entirely on the
Info system itself.
Hunchentoot: Persisting across reboots
In my earlier article on running Hunchentoot behind Apache, I mentioned that it would not be very difficult to have Common Lisp persist your runtime state across a system reboot. Well, after a bit of work, I now have that support available. I’ve revised the article to reflect these changes, so please read there for more information!
Ready Lisp for OS X Leopard
After upgrading my system to Leopard this weekend, I decided to refresh Ready Lisp as well. It now contains both 32-bit and 64-bit builds of SBCL (which has been bumped to 1.0.11), so if you have a Core 2 Duo machine, you’ll be running Lisp at full 64-bit! Alas, Emacs itself cannot support 64-bit as a Carbon app, because there are no 64-bit Carbon libraries. SLIME has also been updated, to CVS latest as of today. Aquamacs is still the same version at 1.2a.
I did spend several hours trying to build a fully Universal
package that would run on PowerPC as well (I have a PowerBook G4 in
addition to this MacBook Pro), but it seems Leopard has broken the
PowerPC port of SBCL. Some of the core OS structures have changed,
such as os_context_t.
Ready Lisp is now being versioned according to the SBCL version it contains, which makes today’s release ReadyLisp-1.0.11-10.5-x86.dmg. The older version, which still works on 10.4, can be downloaded here.
NOTE: The recent loading bug for Leopard users has been fixed. Please re-download. Also, it still does not work on OS X 10.4 (Tiger) at the moment. I will have to create a separate build of SBCL for that version this weekend.
A quick Hunchentoot primer
Running Common Lisp behind Apache
Where Lisp lacks today is primarily in easy to use, pre-packaged services. One of these is getting it to run behind Apache, which although easy to do, took a bit of figuring out from several different web pages. Hopefully I can share how simple it is to get such a system running, so you can try out this highly understated environment for yourself. Read More...
Get Lisp running on OS X (easy version!)
A few days ago I posted instructions for getting a freeware based Common Lisp installation running on your Mac. I have since discovered a better alternative: just install LispWorks Personal Edition, a free environment with a superb set of debugging and profiling tools. Note that it does have the restriction that it will only run for five hours at a time. Once you hit the four hour mark, it gives you a warning, after which you should shutdown and restart the environment. But really, if you’re Lisping for more than four hours every day, that’s great news.
The other option is Lisp in a Box, which offers a completely self-contained freeware Lisp environment that’s ready to download and run on your Mac.
Since the Lisp in a Box site has gotten a little stale with
regard to OS X, I’ve created a new package based on Aquamacs, which
I call Ready Lisp. The advantage to this package is that it
downloads as a single Application bundle. You just drag-and-drop it
into your /Applications directory, double-click and
go! You’ll have all of the following tools immediately at your
disposal:
- Aquamacs 1.2a
- SBCL 1.0.10
- SLIME (CVS version 2007-09-27)
But the nicest part for those new to Emacs and Lisp is that everything is pre-configured and setup for you. Once you double-click the packaged application, you will find yourself at a REPL where you can start right away:
CL-USER> (format nil "Hello, world!")
"Hello, world!"
CL-USER>
The disk image is 44 Mb and can be downloaded from my Lisp repository over FTP. Also, please note that this package is for Intel Macs only. If you need an easy Lisp to run on the PowerPC architecture, I suggested you visit the Lisp in a Box site and download one of their packages based on OpenMCL.
Happy Lisping!
Common Lisp on Mac OS X
Read More...