At the same time, I’ve used Feedbooks as a source for ebooks, especially classic literature. Feedbooks provides all the formats you’d expect, and its ePub output looks really nice on the eReader. It also provides reading lists so I can tag content I want to download later, and has the makings of a social network for bookworms through those lists. I frequently download ePubs from Feedbooks and drop them on the eReader via Calibre, so I can keep both current events and literature on the device.

Last night, I took a look at the News section of Feedbooks, and was I impressed! They have a lot of RSS feeds they’re aggregating and formatting, and it looks great on the eReader. Sadly, since I’m using Mac OS X, I can’t use their News Stand application to automate content downloads when I attach the eReader.

But I liked the idea of getting the news formatted content straight from a server; not only would it be faster, but I wouldn’t have to either leave Calibre running or launch it every morning. Since automating the download and installation of Feedbooks news content is an extension of what I’d already done previously for PDF printing, I figured it was time to do a bit more hacking.

Feedbooks has a nice REST API, which they document on their site. While they don’t directly document their news endpoint yet, it’s based on the same service, so it’s easy to pull content using curl, which is really cool. In about three minutes, I was able to put together a little bash script that pulled a book from Feedbooks and drop it on my eReader.

Before I began working on the automated solution, I figured it was time to move everything to launchd, as I said I’d do three months ago. Launchd can start scripts at predetermined times or when a volume is mounted, so it doesn’t rely on the Finder and Automator; instead I can just write a few scripts and stitch them together with launchd directly. I won’t bore you with the details, as there are a lot of good tutorials on how to use launchd; head over to Google and noodle around if you’ve never done anything with it. Instead, I’ll give you another hint: Lingon. With Lingon, writing a launchd plist is as easy as as fillig out a form. For example, I was able to ditch all the Automator junk to detect the eReader and instead create a launchd entry to do it by filling out a form, like this:

Lingon Configuration for Automating eReader PDF Transfers

I wrote a second script that pulls a few Feedbooks news items and drops them in a second news directory; launchd just calls this script on a regular basis so that I now have reasonably up-to-date news stories anytime I cable the eReader. Doing this correctly was a bit finicky; because all of this runs on my laptop, I wanted to make sure that in the process of pulling a file that it wouldn’t overwrite a previous copy. That way, if it wasn’t on the network, the previous file could still be put on the eReader. I ended up using curl to pull content to working files in /tmp, and checking the result code from curl before copying the results to an intermediate spool directory where the results would wait until I tethered the eReader.

Finally, I reworked the transfer script quite a bit to simplify things. It’s now two scripts: transfer.sh, which launchd starts whenever I connect the eReader, and update-ereader.sh, which actually does the updating of both PDF and ePub files from Feedbooks. The new transfer.sh script invokes an Automator action that prompts me once all the files have been moved to the eReader, so I can tether and go easily, or go back and start Calibre and move more content to the eReader.

As is usual with my shell scripting, these scripts demonstrates my cargo cult mentality; there’s probably better ways to do much of this using bash. But I’m pleased that I no longer need to leave Calibre running all the time and yet getting my news is as seamless as getting what I’ve printed. You’re welcome to use these scripts as you see fit, of course; grab this and have fun. A word of warning: expect to do some customization (you’ll want to edit the files and specify paths, and need to set up the launchd magic on your own. Although all of this is still Mac OS X centric, I suspect that if you’re using Linux there may be pieces you can use here, too, especially now that I’ve ditched most of the dependencies on Automator. (I’ve not looked in to how to detect eReader mounts on Linux, though.)

Speaking of cargo cult programming, here are a few tidbits I picked up that may come in handy for others…

Most important to me from a cosmetic perspective was getting spaces back into file names and dropping the PDF extension on files. CUPS happily converts spaces in file names to underscores, which is great for scripting, but looks really ugly on the eReader display. A quick pass over a filename with sed fixed that:
dest=`echo "$base" | sed -e 's/_/ /g' -e 's/.pdf//g'`
Of course, if you’ve got spaces in file names, bash itself is going to get mad when you try to walk over the list of files in a directory; instead of something like
for f in `ls $spool/*`; do... done
write
find ${spool} -type file -print0 | while read -d $'\0' f; do ... done
The first will fail if any file name has whitespace, while the second uses find to grab each file name, terminate it with a null. and pass it to read, which reads the whole file name up to the trailing null appended by find and stashes the resulting file name in the variable f. Nifty trick, that.

One thing that still bugs me about this solution is that because launchd starts the transfer operation on any mount operation, not just the eReader card mount. That’s a launchd behavior; it starts scripts on volume mounts, not a specific volume mount, and gets twitchy if you tell it to watch a file and the file comes and goes (so you can’t trigger on a directory being mounted.) Because I have a card in the eReader, the eReader presents two separate mount events, and launchd invokes the transfer script twice. I’d hacked around that previously using a lock file, which is a usual UNIX pattern to deal with this sort of thing, but didn’t really like it. This version of the scripts uses ps to see if the script is running, like this:

me=$0
ps -ax | grep $me | grep -v grep | grep -v $$ > /dev/null
if [ $? -eq 0 ]; then exit 0; fi

I have this nasty feeling that spawning all those grep commands is actually slower than simply testing for a file on the file system, though. Oh, well — performance isn’t that important, as the entire process is bound by the speed of writing to the eReader’s flash file system over USB anyway.

Finally, by separating the update operation from the mount detection, I can update the eReader when other content generation operations (such as a scheduled news download or my printing something else) occurs. The script that fetches my news kicks the update script, as does the cups printing job — I just stick a call to the update-ereader.sh script as the value of the PostProcessing directive in /etc/cups/cups-pdf.conf. (Actually, I’ve got a bigger script than that that runs; it does some stuff to try to strip margins and growls completion of each print job… but I’m not ready to talk about that, as it’s shamefully fragile at the moment.)

In the mean time, here’s a revised script for moving the printed PDF files from a spooling directory to the eReader on connection. The setup is the same as before; simply kick the script with a Folder Action.

#!/usr/bin/env sh
PATH=/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
export PATH

readermain="/Volumes/PRS 700"
readercard="/Volumes/700 CARD"
spool="/Users/kf6gpe/.cups-pdf-spool"
pdfdest="$readercard/PDFs/"

growl()
{
    message="$*"
    which growlnotify > /dev/null
    if [ $? -eq 0 ]; then
        echo $message | growlnotify -t "eReader" -p -2 -a /Applications/Preview.app
    fi
}

if [ -f "/tmp/prs-busy" ]; then
    exit 0;
fi

if [ -d "$readercard" ]; then
    touch /tmp/prs-busy
    growl "Device detetected.";
    for f in `ls $spool/*.pdf`
    do
        cp $f "$pdfdest"
        if [ $? -eq 0 ]; then
            rm -f $f
            growl "Transferred `basename $f`."
        fi
    done
    growl "PDF transfer complete.";
    rm /tmp/prs-busy
else
    rm /tmp/pre-busy 2>&1 /dev/null
fi

exit 0

The changes are pretty self-explanatory. In brief:

1. Have use Preview’s icon, in case Calibre isn’t installed.
2. Only look for the eReader’s card; there’s really no reason to look for both volumes. 
3. Use the lock file /tmp/prs-busy to ensure that the actual movement of the files doesn’t occur while it’s actually running. 

Of these changes, (3) was certainly the most important, because if you mounted another volume (say, a digital camera) while the script was doing things, weird things could happen. In practice, I never saw anything amiss, but this makes me sleep better at night.

After some digging around and realizing that I don’t have ppdc I grabbed a PPD file for a generic Postscript printer and started hacking. 

Download ereader.ppd

The results work pretty well, although I see goofy margins from some applications such as TextMate.

Next up? Ditching the Folder Action script I wrote about yesterday in favor of launchd.

While I’ve tried various ebook solutions on PDAs over the years, I’ve never been particularly happy with PDF handling on mobile devices.  I’ve watched with interest the growing market for ebooks on devices including the Sony eReader and the Amazon Kindle, although until recently neither has had particularly good PDF handling either.

Last month I laid hands on a Sony eReader, and really liked what I saw. PDF presentation with later firmware in the PRS 505 is much improved over previous firmware releases, and both the PRS 505 and PRS 700 support Secure Digital cards. As USB devices, these products show up as a mass storage device when mounted on Mac OS X. As an added bonus, Kovid Goyal’s Calibre application supports both format translation and automatic harvesting of Web content from RSS feeds. I have to admit that it’s pretty spiffy to get up in the morning, grab the eReader from my desk and have the latest content from both The New York Times and The Economist at my fingertips. In conjunction with the large number of freely available books from Feedbooks, it’s a leisure reader’s dream.

Although the eReader’s appearance as a mass storage device in the Mac OS X Finder is useful, I quickly tired of downloading papers and manually copying them to the device. Intuitively, it seemed that what I wanted to be able to do was to treat the eReader as another printer.

Upon reflection, this idea is quite compelling. It doesn’t require me to change my work flow at all; moreover, there is something cool about the idea of an eInk device being directly accessible as a printer.

First on the list was creating a printer that saves its output as PDF files. This is no harder than installing and configuring CUPS-PDF for Mac OS X, a build of CUPS-PDF from codepoetry that streamlines printing to PDF files. CUPS-PDF let me print documents to PDF without the need to choose “Save as PDF” anywhere or enter a file name.

CUPS-PDF is actually more useful than it sounds, because once I installed it I could easily create PDF content for the eReader from sources other than PDF documents.  While Calibre converts between a number of formats and has both command-line and GUI interfaces, I quickly found that in practice the additional number of steps meant that I didn’t put the content on the eReader but printed it or pasted it to Evernote anyway.

By default, CUPS-PDF dumps its output in a directory on the desktop. This is fine, but I’d already established a directory hierarchy for eBooks and PDFs anyway, so I changed that. You can, too: simply open up Terminal and as root using sudo edit /etc/cups/cups-pdf.conf and change the Out directive. (As I recall, you’ll need to reboot your system for the change to take effect.) As an added convenience, I shared this printer using Mac OS X printer sharing so I could print to the eReader from any computer on our home network.

Of course, I wanted to be able to create PDFs for the eReader whether or not the eReader was connected. I was impressed that Calibre handled news transfers automatically; ideally the process of connecting the eReader should update not just the Calibre news stories on the eReader, but transfer any new PDFs I had created as well.

Given that the eReader’s memory shows up as folders on Mac OS X in /Volumes, I knew it was time to see what Mac OS X Automator could do. Within an afternoon, I had an Automator action that moves PDFs to the eReader every time it mounts, complete with Growl status notifications.

The trick was to take advantage of Mac OS X’s Folder Actions, which can run a script any time the contents of a folder changes. By hooking a Folder Action to the /Volumes, I can trigger the PDF transfer whenever the eReader is connected, because on connection the eReader’s storage appears as directories in /Volumes.

I use a simple Bourne shell to actually perform the document transfer. The script looks like this:

#!/usr/bin/env sh
PATH=/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin
export PATH

readermain="/Volumes/PRS 700"
readercard="/Volumes/700 CARD"
spool="/Users/kf6gpe/Documents/eBooks/Spool"
pdfdest="$readercard/PDFs/"

growl()
{
    message="$*"
    which growlnotify > /dev/null
    if [ $? -eq 0 ]; then
        echo $message | growlnotify -t "eReader" -p -2 -a /Applications/calibre.app
    fi
}

if [ -d "$readermain" -a -d "$readercard" ];
then
    growl "Device detetected.";
        for f in `ls $spool/*.pdf`
        do
            mv $f "$pdfdest"
            growl "Transferred `basename $f`."
        done
    growl "PDF transfer complete.";
fi

You’re welcome to the script. If you take it, be sure to update the readermain, readercard, spool, and pdfdest variables, as follows:

• readermain should be the path to the eReader’s directory for its main storage.
• If you use a memory card with your eReader, readercard should point to the path to the card. (If you’re not using a memory card, you’ll need to remove this variable and modify the if statement to test only for the presence of the eReader’s main directory. In addition, you’d probably need to make additional changes if you’re using a PRS 700 with memory cards in both slots.)
• spool must be the directory where CUPS-PDFs dumps your PDFs.
• pdfdest must be the already-created directory on the eReader where you want your PDFs.

Integrating the script with Automator wasn’t hard, but getting it as a Folder Action on the /Volumes directory was tricker than I imagined. To do this, follow these steps:

1. Start Automator. (It’s in Applications).
2. In the window that appears, choose “Custom” and press “Choose”.
3. From the Library of the Actions Pane, choose “Utilities” and drag “Run Shell Script” to the empty region on the right.
4. In the “Run Shell Script” that appears, choose /bin/sh as the shell and paste the aforementioned shell script in the main region.
5. Save the workflow using “Save As…” from the “File” menu. This is important, because once you export it as a Folder Action, you can’t seem to edit the results easily. I learned this the hard way.
6. Save the script as a plug-in by
   1. Choose the “Save as Plug-in…” from the “File” menu.
   2. In the dialog that appears, select “Folder Actions” as the plug-in type.
   3. Select the “Attached to Folder” menu and choose “Other…”
   4. In the file dialog that appears, type a ~. A new input line labeled “Go to the folder:” appears.
   5. In input line, delete the ~ you typed and enter /Volumes. Press “Go”.
   6. Press “Open”.
   7. Give the plug-in a reasonable name.
   8. If it’s visible, be sure that the “Enable Folder Actions” box is checked.
   9. Press “Save”

Phew!

Frustratingly, this didn’t work right away for me. If you have problems, it’s worth reading this page by Ben Waldie, which explains much of what happens in the Finder behind the scenes to make Folder Actions work. Strangely, when I first put all this together it didn’t work because one of the directories the Finder uses (I think it was  ~/Library/Scripts/Folder Action Scripts/, but I really don’t recall now) mysteriously was given read-only file permissions and Automator’s plug-in creation process would silently fail. So if you’ve never used Folder Actions or Automator, it’s worth looking at some of the other tutorials on the Web before you try to wire one to a shell script.

While it’s pretty slick and I’m quite pleased with the results, the resulting interaction between the Macintosh and the eReader still leaves room for improvement.

First, I’d like to add an eReader-specific paper size to the CUPS-PDF printer options for when I print content such as Web pages. Adding a custom paper size to Mac OS X is easy, although for some reason it doesn’t show up for the CUPS-PDF printer. I’m now starting to look at how CUPS uses PostScript Printer Definition (PPD) files to describe printers and figure out how to do this, although frankly the whole thing makes my head spin.

Second, about 90% of what goes to the eReader this way starts its life as a PDF generated using TeX; such is the stuff of a paper typeset by and for computer scientists. I love TeX and its output, especially the wide margins, because the result is so easy to read. Unfortunately, those same margins occupy a ridiculous amount of space on the eReader screen, space that’s probably better used for the text itself. The Comprehensive TeX Archive Network has a script called pdfcrop that determines the bounding box of each page in a PDF and creates a new PDF consisting of pages without their margins, and I’ve been experimenting with that. Either that or more work with CUPS itself would enable me to rid myself of margins, which would make better use of the eReader’s screen.

Nonetheless, much of my career has been spent working within the confines of the Win32 platform. Many mobile platforms such as Qualcomm BREW stage their development environments on top of Win32, providing emulators in which the application you’re writing is linked in as a Win32 DLL. While this has its limitations—emulation isn’t simulation, etc—it’s definitely a good way to go for platform vendors, because the Win32 tool chain is well-understood by countless developers, even if the intricacies of a specific mobile platform isn’t.

At the day job, I recently came across a need to track down a number of memory leaks in a C-based application for Qualcomm BREW. The code had already been written, so it wasn’t feasible to go back and implement a wrapper to the memory management utilities that tracked allocation and free operations using the __FILE__ and __LINE__ macros; even if I could, I also needed to track down a few BREW component instance leaks, which would be considerably more complex to track using wrappers. Because of the need to determine component instance leaks and how the BREW simulator manages its own heap (providing leak reporting, at least), tools like Purify weren’t really an option either.

By hand-editing the include files that define BREW’s object creation and memory allocation routines (AEEShell.h and StdLib.h) I could directly hook the memory allocations, giving me an opportunity to determine the source of the leaks…if only I knew what portions of the code were performing the allocations. Using a dictionary matching pointers to memory or components and information about how those regions re allocated isn’t my idea; it’s hardly new, and frankly, I don’t know where it originated. It is a good idea, though, because it makes the work go a lot faster. By instrumenting allocations to track where in the code the allocation is being made (typically inserting that information in a dictionary keyed by the pointer to the region or component being allocated) and instrumenting the deallocation to release those records, an examination of the resulting dictionary after a run gives you a list of points in your code that may be allocating resources that aren’t freed later. The technique isn’t perfect, of course, especially if you pass references to memory or components around to other systems that you can’t instrument, but it’s a good start. I had a dictionary implementation that I could use to store information about each allocation referenced by pointer; if I could get stack frame data at the points where I hooked the allocator and deallocators, the work would become much easier.

I knew that I should be able to programmatically get stack trace information running under the simulator on Win32, although I had no idea how. Oddly, this doesn’t seem to be common knowledge, either, after pinging a few colleagues on the subject. However, after more reading of MSDN articles and googling than I care to admit, I came across Jochen Kalmbach’s StackWalker class, a C++ class that provides an utterly simple interface to obtain a stack crawl anywhere in your Win32 application. Great stuff, and I’m glad I found it! Using it was far simpler for me than trying to wrap my head (and some new code) around the debugger API that Microsoft provides.

I was quickly able to modify it to meet our needs to run within the Qualcomm BREW simulator and provide stack dumps to a log file; after those changes and a bit of truly shameless hacking on private copies of AEEStdlib.h and AEEShell.h, leak tracking became much easier. At some point I plan on providing a simple BREW component for simulator-only use that incorporates his code and provides much of the same functionality; it may make a good article or blog post in the future. In the mean time, I hope that simply describing the process here helps someone.

This experience provides a situation supporting my belief that a general interest in computing and computing platforms is key to being a good software engineer; if I’d thought too narrowly about the problem as being inherent to an application running on Qualcomm BREW, I might never have decided to add a bit of simulation-specific code to automate the bookkeeping behind my debugging.

Getting a dialect of Common Lisp running on Mac OS X isn’t hard — in fact, if you’re just setting out, an excellent choice is LispWorks Personal Edition. I’ve recently gotten to the point, however, where I’ve wanted to do some work with the Common Lisp Interface Manager, which isn’t supported in LispWorks Personal Edition under Mac OS X, and set out to configure a Common Lisp installation on my MacBook from the ground up.

It wasn’t difficult, although it took some Googling to get all the pieces together; shortly after I finished, someone on the Bay Area Functional Programmer’s mailing list asked about running Common Lisp on Mac OS X, and I put together my notes on the topic and replied. The list is fairly small — less than 300 members — and I promised them and myself that I’d organize the notes and provide them in a more accessible location.

What follows is a step-by-step installation guide to installing Steel Bank Common Lisp (SBCL) and McCLIM on a PowerBook G4; I undertook this from the initial notes I took configuring the MacBook. I chose SBCL because it’s well-supported by the open source community and works well with McCLIM; I have nothing against other Common Lisp implementations, including Clozure. 

A word of warning is in order: I’m comfortable with Common Lisp, but relatively unfamiliar with how Common Lisp programmers handle package distribution. I get the basic idea behind ASDF, of course, but I’m not seasoned in its use. Consequently, I had a get-things-working-and-clean-up-later mentality when I undertook my first SBCL-McCLIM configuration, and this largely remained when I wrote what follows. Other Lisp developers may have better ways to organize their working environments, and I’d welcome positive comments (drop me an email, and we’ll figure out how to incorporate your feedback).

Starting out, you should have a relatively up-to-date Mac OS X box (I’ve done this on Mac OS X 10.4.x and 10.5.x systems). When you’re done, you will have installed Carbon Emacs, SLIME, SBCL,and McCLIM configured to work with the X Windows erver Mac OS X provides, along with darcs. 

Carbon Emacs

Carbon Emacs on Mac OS X provides you with an Emacs instance running as a Mac OS X application. I like it for general editing, as well as the obvious purpose of giving me a place to run SLIME and do my Lisp development.

1. Get Carbon Emacs from its home page. If you need a version for a version of Mac OS X other than 10.5, check here.
2. Mount the disk image you download, and copy Emacs.app to your Applications folder.

Steel Bank Common Lisp

1. Download SBCL. Choose either X or P on this page for the X86 or PPC build, respectively.
2. Unpack the distribution, and open a Terminal to the directory where you’ve unpacked the distribution.
3. Install per the INSTALL instructions. I used the default options, placing SBCL in /usr/local by issuing:

   KF6GPEs-PB-G4:~/Desktop/sbcl-1.0.2-powerpc-darwin kf6gpe$ sudo sh
   Password: <entered password>
   # INSTALL_ROOT=/usr/local sh install.sh

At this point in time, you should be able to run SBCL from the shell.

SLIME

SLIME in Carbon Emacs is swell.

1. Download SLIME. I used CVS in the terminal, stashing the whole thing in a hidden directory. If you use a lot of emacs packages, you may well already have a directory for them, and you can put SLIME there as well.

   KF6GPEs-PB-G4:~ kf6gpe$ cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime
   KF6GPEs-PB-G4:~ kf6gpe$ mv slime ~/.slime

2. Wire SLIME up to your emacs installation. I followed the instructions in the SLIME documentation.
   In a nutshell, it says to add the following to your ~/.emacs:    

      (setq inferior-lisp-program "/usr/local/bin/sbcl")
      (add-to-list 'load-path "~/.slime")
      (require 'slime)
      (slime-setup)

   where
   /usr/local/bin/sbcl is the path to SBCL you specified in the previous section, and
   ~/.slime is the path to the slime directory you specified in the previous step.

You can stop at this point if you don’t want to work with McCLIM; you have a working SBCL
environment using Carbon Emacs and SLIME. To use SLIME, start emacs from the Terminal or
Carbon Emacs and run SLIME using M-x slime.

darcs

Some of the stuff you need for McCLIM is kept in a darcs repository, so you first need to get and install darcs. I used one of the pre-built binaries. Make sure that however you do this, darcs is in your path when you’re done installing, of course.
 

McCLIM

I followed these steps  to build and configure McCLIM from source.

1. You’re going to use ASDF to get various Common Lisp packages, and you need a place to put the resulting files, as well as to tell SBCL where that place is. Make a directory ~/lispsystems in your home directory, and configure SBCL by adding the following to your ~/.sbclrc file:

   (require 'asdf)
   (push (truename "~/lispsystems") asdf:*central-registry*)

2. Fetch the McCLIM sources.

   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ cvs -z3 -d:pserver:anonymous:anonymous@common-lisp.net:/project/mcclim/cvsroot co mcclim
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ ln -s mcclim/mcclim.asd .
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ ln -s mcclim/clim-examples.asd .

3. Fetch McCLIM’s dependencies: the Common Lisp Library for X, spatial-trees, and flexichain:

   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ darcs get http://common-lisp.net/~crhodes/clx
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ ln -s clx/clx.asd .
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ curl http://ftp.linux.org.uk/pub/lisp/cclan/spatial-trees.tar.gz > spatial-trees.tar.gz
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ tar -xvzf spatial-trees.tar.gz
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ curl http://common-lisp.net/project/flexichain/download/flexichain_latest.tgz > flexichain_latest.tgz
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ tar -xvzf flexichain_latest.tgz
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ ln -s spatial-trees-0.2/spatial-trees.asd .
   KF6GPEs-PB-G4:~/lispsystems kf6gpe$ ln -s flexichain_1.5.1/flexichain.asd .

4. Build the McCLIM system. Fire up Carbon Emacs, run SLIME using M-x slime, and enter:

   CL-USER> (asdf:oos 'asdf:load-op :mcclim)

   Be prepared to wait a while as the system builds for the first time. 

5. To see if everything works as expected, you can build the samples:

   CL-USER> (asdf:oos 'asdf:load-op :clim-examples)

6. To play with the samples:

   CL-USER> (clim-demo::run-test 'clim-demo::demodemo)

You also have the option of getting McCLIM using clbuild, as this page describes. That worked for me under Mac OS X 10.5, but did not under Mac OS X 10.4, and I didn’t bother to investigate what was different. 

Good luck and happy hacking!

With the imminent publication of my latest book, Beginning Java™ ME Platform (Beginning from Novice to Professional), it’s again apparent that I should put more effort into reaching out to both those I know and those who read my work. Not only is this an important part of publicity for me as an author, but it’s also a service to you, my readers, because it gives me an opportunity to keep you up to date. I only hope that I am more successful in keeping you up to date than I am self-publicity, something I have generally neglected. 

Hence, this blog.

I’m not certain what all I will post here, or how frequently I will post. You can certainly expect any updates or feedback on my books, of course, but I’m also planning on using this as a working notebook for other technical musings. I don’t have any plans to become a career blogger and make this a central part of my professional activities; to be frank I think there’s too much of that on the Internet already! Instead, I think this is going to fill a very narrow nice, with me posting the occasional update to a previous (probably paper) publication, various tips and tricks I’ve picked up in my engineering career, and possibly some engineering notes about things I’ve found difficult in the hopes that capturing it here will help others.

Thanks for stopping by!