Friday, September 8, 2006

DEFSETF misadventure

While working through some new unit-tests for Graphic-Forms, I happened to discover an assertion failure in an existing test occurring when I run the test more than once. Strangely, it happens on LispWorks and SBCL, but not CLISP. -- Drat! -- The failing assertion validates an attribute value set on a test layout manager (which is created anew every time the test runs), then a bit further on the test sets this attribute to a different value and checks it again. The failure scenario is on the second run. Right now, it looks like the 2nd value from the first run has persisted and that's why the assertion fails.

The culprit appears to be a `short form' DEFSETF defined in Graphic-Forms so application code can SETF attributes on layout managers. Or perhaps the culprit is an attribute setter function upon which the DEFSETF is implemented?

These layout manager attributes are stored in per-object lists; there is no global state in my code where these attributes are concerned. Perhaps there is some memoization being done behind the scenes? It's very puzzling.

Sunday, September 3, 2006

my copy of AMOP arrived

A few days ago, I received a used copy of AMOP ordered through Amazon. This was getting to be a long-overdue stage in my development as a Lisper, because while I have written some MOP-using code (portably, thanks to Pascal Costanza's excellent Closer to MOP library), I had not yet actually studied the MOP from end to end.

One little suggestion for my fellow used-book shoppers: when a seller describes a used-copy's condition as "acceptable -- light underlining and notes in blue pen throughout," I heartily recommend moving on to the next seller. Because even though this copy arrived exactly as described, I had no idea how completely annoying it is to try to read text on the page when the previous owner has underlined nearly every single line, even in the code samples, and added little squiggles and extra notes because apparently the underlining wasn't enough! And in blue pen, which nicely stands out! Aargghh.

Anyway. Obviously, this book demystifies what the MOP is all about. Reading it gets one to thinking "hey, I could do that." Sort of the same feeling one gets while taking an operating system class in college -- getting into the nuts and bolts, one realizes that a lot of what makes up a kernel is just record-keeping (yes yes yes, there are nasty details, too). Implementing a layered architecture with good performance while preserving extensibility is a neat trick, though. This book gives me much to think about.