Re: Metaclass & McCLIM revisited

BTW, it seems that a few years ago Franz published its proprietary CLIM2 
source on github with an open source license. I gave it a quick look but 
it did not seem easy to build.

On 1/29/2026 2:38 PM, Paul Werkowski (as pw at snoopy dot qozzy dot com) 
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

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