Re: Metaclass & McCLIM revisited

Fair enough!


BR,
/Alexey


On Thursday, January 29th, 2026 at 20:38, Paul Werkowski <[email protected]> wrote:

> LW's CLIM was the reason I invested personal money to buy LispWorks Pro
> many years ago, when it was still HCL, for work. Mike MacDonald
> starting McCLIM got me interested. Now, retired, I use the Hobbiest
> edition which does not include CLIM.
> 
> On 1/29/2026 2:14 PM, Alexey Veretennikov wrote:
> 
> > Hi,
> > 
> > Very interesting. What advantage the McCLIM has over the LW's own proprietary CLIM? Couldnt with LW Pro one get the CLIM for less efforts (in time/money) than to properly convert McCLIM to LW?
> > 
> > BR,
> > /Alexey
> > 
> > Sent from Proton Mail for Android.
> > 
> > -------- Original Message --------
> > On Thursday, 01/29/26 at 19:16 Paul Werkowski (as pw at snoopy dot qozzy dot com) [email protected] wrote:
> > Back in May I wrote that the new release of open source CLIM, McCLIM,
> > failed to compile on Lispworks.
> > The main problem was the inclusion in the source code a new file,
> > dynamic-vars.lisp, which introduced a CLOS class with a non standard
> > metaclass, CLASS-WITH-DYNAMIC-SLOTS.
> > This was to implement an object slot scheme in which the slot-value of
> > specified slots were initialized to be an instance of class
> > DYNAMIC-VARIABLE which would contain the actual value of interest. The
> > idea being that cl:slot-value and (setf slot-value) would access
> > (dynamic-variable-value object slot-name), not the container instance.
> > All of this to support the concept of thread-local slots. An instance of
> > class TLS-RECORD-CONTEXT would contain graphic context info needed by
> > the graphics backend for drawing to screen.
> > 
> > It seemed that LispWorks could not deal with that metaclass stuff. It
> > was suggested to me by the author of that code that LispWorks's
> > implementation of the ANSI MetaObject Protocol was somehow deficient.
> > 
> > I decided to find out what it would take to get that system to work in
> > LispWorks. I began by chasing symptoms. The issues encountered were:
> > 
> > * 1. Slot Initialization.
> > * 2. Slot-value customization via slot-value-using-class.
> > * 3. Automatic slot-accessor generation.
> > 
> > The first was very puzzling, the second easy. The third at first crazy
> > but finally interesting.
> > 
> > So I came up with something that worked. McCLIM compiled and worked
> > properly as before. Tread-Local slots worked as designed.
> > 
> > I was not at all pleased with the results. The name of old Rube Goldberg
> > and his wacky inventions came to my mind. Nested
> > ENSURE-CLASS-USING-CLASS :AFTER methods, first to insert the metaclass
> > name as an explicit superclass to a user class in order to get
> > initialize-instance to be called, then creating a new class metaobject
> > after removing slot accessor methods and then re-installing new methods,
> > all to supress anoying method redefinition warnings.
> > 
> > I decided I needed to take a break for awhile and went off to visit an
> > old friend, CMUCL. In 1994, I spent four or five months of nights and
> > weekends finishing the port from RISC workstations to x86 CISC PC
> > running on FreeBSD Unix. That effort eventually led to a fork resulting
> > in SBCL. This time I assisted current cmucl maintainers attempting to
> > get McCLIM running on that CL.
> > 
> > So, the result of all that is: there is nothing deficient with
> > LispWorks' CLOS. All(?) the free CL implentations use Portable Common
> > Loops (PCL) for an object system. PCL was created by Xerox cica 1986 and
> > was one of several lisp object system to influence the CLOS of the ANSI
> > spec, a predecessor to or prototype of CLOS. The "closer-mop" quicklisp
> > package tries to bridge the difference. What I remember most of PCL in
> > the 90's is that it took about 4 hours to compile on my minimally
> > configured 486 PC.
> > 
> > McCLIM is only portable among Lisps that use PCL for an object system.
> > 
> > ------
> > What's the difference between PCL and LW CLOS?
> > 
> > Start at the beginning with object initialization. The DV code starts
> > with CL:ALLOCATE-INSTANCE.
> > 
> > From CLHS,
> > "The generic function allocate-instance creates and returns a new
> > instance of the class, without initializing it. When the class is a
> > standard class, this means that the slots are unbound; when the class is
> > a structure class, this means the slots' values are unspecified."
> > 
> > Also,
> > " The consequences of adding methods to allocate-instance is
> > unspecified. This capability might be added by the Metaobject Protocol."
> > 
> > The DV code (written for PCL) uses generic-function
> > cl:allocate-instance, specialized to the metaclass
> > (class-with-dynamic-slots), to install instances of Dynamic-Variable in
> > specified slots. Lispworks executes that code and then ensures the slots
> > are unbound.
> > 
> > So, what to do? First thought was to move that code to
> > initialize-instance :after only to find that initialize-instance was not
> > called at all by LW (or PCL). Apparently, I-I is a thing that only
> > metaclasses STANDARD-CLASS and STRUCTURE-CLASS know about. I found that
> > installing the metaclass name as an explicit superclass, eg. (defclass
> > myclass (class-with-dynamic-slots) ...) got past that obstacle.
> > 
> > More correct is to use MAKE-INSTANCE specialized to the metaclass name.
> > A bonus here is that on entry to make-instance, default and specified
> > :intargs have been resolved and all that is needed is to insert those
> > values into a new DV instance and install that in the slot.
> > 
> > Second, SLOT-VALUE.
> > 
> > The CLOS spec suggest implementations have function SLOT-VALUE call GF
> > SLOT-VALUE-USING-CLASS. PCL does this for the function and also for
> > default accessor methods specified in DEFCLASS slots. PCL's
> > slot-value-using-class expects the second argument to be a
> > SLOT-DEFINITION metaobject. LispWorks second argument to slot-value is
> > slot-name (a symbol), and uses CLOS::STANDARD-INSTANCE-ACCESS or
> > (CLOS::FAST-STANDARD-INSTANCE-ACCESS) for both slot-value and default
> > acccessor methods. Thus slot-value of a DV slot picks up the DV instance
> > instead of its imbedded value. Closer-mop arranges to find the proper
> > slot-definition metaobject by name and passes that to
> > slot-value-using-class.
> > 
> > Third, Slot Accessor Methods.
> > 
> > So, how to get those optimized accessor methods to do the right thing.
> > It turns out that LW's CLOS has the MOPery to do that.
> > CLOS:READER-METHOD-CLASS, CLOS:MAKE-READER-METHOD,
> > CLOS:WRITER-METHOD-CLASS and CLOS:MAKE-WRITER-METHOD do the job.
> > 
> > A downside is that a few things neither documented nor exported from
> > :CLOS are needed.
> > 
> > Finally, attached is build-mcclim.lisp which, when loaded, generates an
> > environment and and a function of that name that will (with a bit of
> > luck) fetch (via quicklisp) all the needed software, compile, load and
> > patch McCLIM and optionally the clim demo/examples system.
> > This presents a table of 68 push-buttons, each of which will produce a
> > possibly interactive graphic. All but the last three, starting with the
> > word 'concurrent', appear to work. There is also a test suite,
> > "mcclim/test" with results:
> > 
> > Did 2200 checks.
> > Pass: 2191 (99%)
> > Skip: 0 ( 0%)
> > Fail: 9 ( 0%)
> > 
> > NOTE! A working X11 server must be installed. I use "VcXsrv X Server" on
> > Windows 10 which can be obtained from vcxsrv.sourceforge.net.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html