Monday, December 18, 2006

shell extensions gotcha

Jeff Shrager posed this question back in September regarding his desire to create a Windows Explorer shell extension using Lisp (not specifically CL). I replied thusly and he later indicated that he'd had success.

It didn't occur to me at the time, but I've just now discovered that implementing shell extensions via certain implementations of Lisp, or any other single-instance runtime environment for that matter, might not be such a good idea. This thread has discussion of a similar idea, in this case involving the CLR. As a couple knowledgeable people point out in the ensuing discussion, the problem is that every application that does a mundane thing like invoking the common file dialog suddenly gets the runtime you used for your extension (Lisp or CLR or whatever) injected into it. Chaos could ensue for several reasons, for example if your runtime needs to reserve large chunks of virtual address space for itself that the host application isn't expecting and/or can't satisfy. Not to mention the potential inability of two such runtimes to co-exist in the same process, such as when you develop a GUI app that uses the same (or different!) version of said runtime.

There are easy-to-find examples and shareware floating around the Net for doing this. Nonetheless, I'd take Jesse Kaplan's and Raymond Chen's opinions at face value and think really hard about which Lisp I was using before venturing down such a path.

Saturday, December 16, 2006

AllegroCL 8.0 port

On the spur of the moment, I decided to try porting Graphic-Forms to AllegroCL 8.0. After a few hours work, I got all of the test programs running. It was fairly straightforward. These days, it seems that the main complication in porting Graphic-Forms is translating stdcall callback definitions into the vendor's particular FFI vocabulary. A CL whose dynamic FFI is a second-class citizen is likely to be a troublesome porting target, though.

Sunday, December 3, 2006

new job

Tomorrow, I'm starting a new job that is mostly Java programming but may also involve some C++ and C#. At least in the beginning, I'll be working on non-graphical library code. The problem domain is pretty interesting and (for me) brand new.

Does this mean the end of my Lisp hacking days? Not at all. Throughout my career, I've consistently worked on projects in my free time -- I tell people that if programming wasn't my job, it would be my hobby. And I know there are lots of people who feel the same way. Lisp multiplies the fun by 10x (or whatever factor you want to plug in, it's large). I am and will continue to be an enthusiastic member of the Lisp community.

I am returning to the so-called commercial software development world armed with a broader view of how to solve problems. I also have a pragmatic view of Java programming as a technology, and Java/C++ programmers as highly capable and intellectually stimulating folks with whom to work. It will be nice to collaborate with folks on a face-to-face basis.

Meanwhile, I continue to work on Graphic-Forms and look forward to making the next release available (I'm thinking January is likely). My McCLIM backend project continues as well. I salute the SBCL developers for getting to the 1.0 stage and hope to find ways of contributing to the Win32 port. I continue to be one of the binary package maintainers for CLISP. And there are some other projects that I have cooking.

If only there were more hours in each day!

Friday, December 1, 2006

Graphic-Forms version 0.7.0

Release 0.7.0 of Graphic-Forms, a Common Lisp library for Windows GUI programming, is now available. This is an alpha release, meaning that the feature set and API have not yet stabilized.

Here is what's new in this release:

. Implemented cursor support. Applications can choose from the system-defined cursors or load them from external files. Also provided are convenience macros GFW:WITH-CURSOR and GFW:WITH-WAIT-CURSOR.

. Implemented a new layout manager called GFW:BORDER-LAYOUT which allows applications to assign children to regions around the perimeter of a window or the center.

. Implemented GFS:OBTAIN-SYSTEM-METRICS as a higher-level interface to the Win32 GetSystemMetrics() API. It returns a hash table containing slightly post-processed system metrics values.

. Implemented the function GFW:PROCESS-EVENTS to help applications flush the event queue of pending events.

. GFW:APPEND-ITEM now accepts an optional classname argument so that applications can use custom item classes.

. Implemented a new macro GFW:WITH-ROOT-WINDOW which manages the lifetime of an instance of GFW:ROOT-WINDOW for use within the macro body.

. Fixed ASDF loading problems.

The README.txt file in the release zip file also has additional important information about this release.

Download the release zip file here:

The project website is: