Re: Metaclass & McCLIM revisited

CLIM is not just graphics. The major thing for me is the presentation 
system which maps a data object to what appears on screen, a 
'presentation' of a 'presented data object'. In my for work environment, 
A PDO was a location of a sonar echo and the presentation was the 
location of that echo on a background graphic of an Electronic Nautical 
Chart. In other applications perhaps the PDO is employer data of someone 
depending on a particular 'view'. This is all from a MIT paper from 
someone who's name I don't recall.

I have been working on a CLIM backend (rather than CLX) using CAPI. The 
drawing part was easy, I've gotten some 'gadgets' working but stalled on 
'menus'. The need to use apply-in-pane-process or execute-with-interface 
doesn't help.

On 1/29/2026 4:16 PM, Matthew Weber (as webermatthewr at gmail dot com) 
wrote:
> I was under the impression that CLIM was an older implementation and
> that modern GUI was generally done through CAPI.
> Is there a reason to prefer the CLIM implementation to CAPI?
>
> On Thu, Jan 29, 2026 at 7:50 PM Alexey Veretennikov (as alexey dot
> veretennikov at protonmail dot com) <[email protected]> wrote:
>> 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
> _______________________________________________
> 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